headers
bugtrack | 1 Feb 2005 21:27

[DBMail 0000170]: dbmail-users -c -P does not update the password


A BUGNOTE has been added to this bug.
======================================================================
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=0000170
======================================================================
Reported By:                bb
Assigned To:                
======================================================================
Project:                    DBMail
Bug ID:                     170
Category:                   Command-Line programs (dbmail-users, dbmail-util)
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
======================================================================
Date Submitted:             31-Jan-05 20:31 CET
Last Modified:              01-Feb-05 21:27 CET
======================================================================
Summary:                    dbmail-users -c -P does not update the password
Description: 
The password stored in the DB is not updated.
======================================================================

----------------------------------------------------------------------
 bb - 31-Jan-05 21:09 CET 
----------------------------------------------------------------------
At first I didn't think that matters but, it is on Linux Fedora Core 2
2.6.10-1.8_FC2smp
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugtrack | 2 Feb 2005 22:48

[DBMail 0000171]: max() is indexable in mysql but not in postgresql causing extreme slowness every folder open


The following bug has been SUBMITTED.
======================================================================
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=0000171
======================================================================
Reported By:                OutboundIndex
Assigned To:                
======================================================================
Project:                    DBMail
Bug ID:                     171
Category:                   Database layer
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
======================================================================
Date Submitted:             02-Feb-05 22:48 CET
Last Modified:              02-Feb-05 22:48 CET
======================================================================
Summary:                    max() is indexable in mysql but not in postgresql causing extreme slowness every folder open
Description: 
An often used sql query is fast on mysql (indexed) but unbearably horribly
slow on postgresql once dbmail is full of a lot of messages (400,000 and
maybe a lot less.) Particularly easy to feel when using squirrelmail.
Postgresql cannot and does not use indexes on a min() or max() function.
Blazingly fast performance in postgresql is restored by using the current
value of the next sequence instead of max()+1 in the query.
======================================================================

Bug History
(Continue reading)

Permalink | Reply | 2 comments |
headers
John Hansen | 3 Feb 2005 00:24
Picon

Re: [DBMail 0000171]: max() is indexable in mysql but not in postgresql causing extreme slowness every folder open

> An often used sql query is fast on mysql (indexed) but unbearably horribly
> slow on postgresql once dbmail is full of a lot of messages (400,000 and
> maybe a lot less.) Particularly easy to feel when using squirrelmail.
> Postgresql cannot and does not use indexes on a min() or max() function.
> Blazingly fast performance in postgresql is restored by using the current
> value of the next sequence instead of max()+1 in the query.

Nextval is a bad idea since it increments the sequence counter.

Instead of SELECT max(columnname) FROM tablename; use:

SELECT columnname FROM tablename ORDER BY columnname DESC LIMIT 1;

similarly

SELECT columnname FROM tablename ORDER BY columnname ASC LIMIT 1;

for min().

This btw,. is indexable on both MySQL and PostgreSQL.

... John
Permalink | Reply | 0 comments |
headers
Aaron Stone | 3 Feb 2005 01:24
Picon
Picon

Re: [DBMail 0000171]: max() is indexable in mysql but not in postgresql causing extreme slowness every folder open

On Wed, Feb 2, 2005, John Hansen <john@...> said:

> Instead of SELECT max(columnname) FROM tablename; use:
> 
> SELECT columnname FROM tablename ORDER BY columnname DESC LIMIT 1;

LIMIT is not in ANSI, so MaxDB (formerly SAPdb) and Oracle would cry.

This could be a case where we need a variable that's set in the database
shims and used in db.c, but I think that the ANSI syntax is something
like:

SELECT TOP 1 FROM table... ASC/DESC

In which case we've got some trouble.

Aaron
Permalink | Reply | 0 comments |
headers
Kasper Haagensen | 3 Feb 2005 17:04
Picon

Are this table in use?


Hi

Can somebody help me out here.
The following database, are they in use ind the 2.0.3 relaese?
And if dbmail is using them, how does it work?

dbmail_acl
dbmail_auto_notifications
dbmail_auto_replies 

Kasper Haagensen
Permalink | Reply | 2 comments |
headers
Aaron Stone | 3 Feb 2005 17:26
Picon
Picon

Re: Are this table in use?

On Thu, Feb 3, 2005, Kasper Haagensen <k <at> sper.dk> said:

> Can somebody help me out here.
> The following database, are they in use ind the 2.0.3 relaese?
> And if dbmail is using them, how does it work?

Wolfram Kraushaar did a great job writing database docs:
http://dbmail.org/dokuwiki/doku.php?id=er-model

> dbmail_acl

This is for shared mailboxes.

> dbmail_auto_notifications
> dbmail_auto_replies 

These are for auto_notifications and auto_replies, respectively.

Send a notification to a mail-address when new mail arrives at the
mailbox. Needs AUTO_NOTIFY=yes in the configuration file (usually
/etc/dbmail.conf)

Send an auto reply to back to the sender when new mail arrives at the
mailbox. Can be used for Out-of-office Replies, but see the notes. Needs
AUTO_REPLY=yes in the configuration file (usually /etc/dbmail.conf) (NOTE:
Unlike normal out-of-office-replies, AUTO_REPLY in DBMail does NOT
remember if it already responded to an e-mail. If the user is subscribed
to a Mailing List one can easily build a mail-loop.)

Aaron
(Continue reading)

Permalink | Reply | 1 comment |
headers
bugtrack | 3 Feb 2005 19:01

[DBMail 0000057]: direct mailforwarding with email+folder <at> server


A BUGNOTE has been added to this bug.
======================================================================
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=0000057
======================================================================
Reported By:                maXXmaster
Assigned To:                aaron
======================================================================
Project:                    DBMail
Bug ID:                     57
Category:                   PIPE delivery (dbmail-smtp)
Reproducibility:            N/A
Severity:                   feature
Priority:                   normal
Status:                     acknowledged
======================================================================
Date Submitted:             23-Jul-04 23:37 CEST
Last Modified:              03-Feb-05 19:01 CET
======================================================================
Summary:                    direct mailforwarding with email+folder <at> server
Description: 
it doesn't seem that there is a way to store "special" mails like spam to a
different folder than INBOX when pipeing the message to dbmail-smtp. i'm
not sure if it is an imap-standard, but many imapservers allow you to send
a message to emailaddress+foldername@...

is there a way to realise that?
======================================================================

----------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kasper Haagensen | 3 Feb 2005 19:21
Picon

SV: Are this table in use?

Great.... Thx...

Kasper

-----Oprindelig meddelelse-----
Fra: dbmail-dev-bounces@...
[mailto:dbmail-dev-bounces@...] På vegne af Aaron Stone
Sendt: 3. februar 2005 17:27
Til: DBMAIL Developers Mailinglist
Emne: Re: [Dbmail-dev] Are this table in use?

On Thu, Feb 3, 2005, Kasper Haagensen <k <at> sper.dk> said:

> Can somebody help me out here.
> The following database, are they in use ind the 2.0.3 relaese? And if 
> dbmail is using them, how does it work?

Wolfram Kraushaar did a great job writing database docs:
http://dbmail.org/dokuwiki/doku.php?id=er-model

> dbmail_acl

This is for shared mailboxes.

> dbmail_auto_notifications
> dbmail_auto_replies

These are for auto_notifications and auto_replies, respectively.

Send a notification to a mail-address when new mail arrives at the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matt Benjamin | 4 Feb 2005 15:33

Re: Dbmail Dev Question (Hash Table)

Ilja,

a. Joined the list.

b. Implementing a feature--but I need it in a stable/production usable 
branch quickly--I don't mind porting it forward, if its useful.  Is the 
CVS version approprate to run as a mail server for real users at 
present?  (I'd find it easier to believe a snapshot...)

c. That's a good answer.

Matt

Ilja Booij wrote:

>Hi Matt,
>
>Matt Benjamin <matt@...> writes:
>  
>
>>I'm trying out something with the Dbmail 2.0.3 source that might require 
>>a string table/hash table data structure.  On the off chance that I 
>>write anything useful and send a patch, and you don't throw it away, I 
>>wondered if you had any preference on how best to do that, ie,
>>    
>>
>
>Are you implementing some new feature? Of fixing something? The chances of
>an invasive patch like the use of a completely differenent data structure
>getting into dbmail 2.0.x are pretty slim. You might be better of working
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul J Stevens | 4 Feb 2005 15:55
Picon
Favicon
Gravatar

Re: Re: Dbmail Dev Question (Hash Table)


Matt Benjamin wrote:

> b. Implementing a feature--but I need it in a stable/production usable 
> branch quickly--I don't mind porting it forward, if its useful.  Is the 
> CVS version approprate to run as a mail server for real users at 
> present?  (I'd find it easier to believe a snapshot...)

Matt, the cvs-version is pretty safe to use atm, but actual real world exposure 
has been limited, so production ready it is not.

I'm working on finishing the authldap layer, which means things are changing 
rapidly in very specific parts of the code. But no patches will land in cvs 
until the test-frame is finished, and both authldap.c *and* authsql.c validate 
against the tests. Eta is about a week from now, with a bit of luck :-) The 
reason I'm rushing the schedule for 2.1 is that I too need a feature (ldap), and 
plan to deploy 2.1.0 or whatever it'll be called on production machines asap.

Please *do* tell us more about what your thinking. Me very curious...

--

-- 
   ________________________________________________________________
   Paul Stevens                                         paul@...
   NET FACILITIES GROUP                     GPG/PGP: 1024D/11F8CD31
   The Netherlands_______________________________________www.nfg.nl
Permalink | Reply | 0 comments |

Gmane