Ok Jesse, thanks for the pointer.
Looks like db_imap_append uses its own version of the insertion logic and still inserts messages with empty
unique_ids during the insertion sequence. That should be fixed, if only be wrapping this in a transaction.
Come to think of it, wouldn't transactions actually do?
db_copymsg looks ok to me.
Jesse Norell wrote:
And the second query changed to: [SELECT message_idnr, seen_flag,
recent_flag FROM dbmail_messages WHERE mailbox_idnr = '9' AND status <
'2' AND length(unique_id) > 0 ORDER BY message_idnr ASC]
unique_id!='' should go where not absolutely required.
Any objections to removing that particular restraint from the code?
I really don't know how that one ever got in. If anyone happens to know,
please speak or be silent for ever
more :-) In my database there are no messages with an empty unique_id. And
there shouldn't be. Such sanity
checks shouldn't hog the real-time performance, and be deferred to
asynchronous maintenance like dbmail-util.
Obviously from my last post, I'm not through my inbox yet...
As I mentioned, in at least one place in old (1.x) dbmail mail insertion
(from memory, it seemed to be in the imap code, with a copy command
or somesuch) the status flag was not used to mark a message that
wasn't yet fully inserted (I think everywhere else the status was set
to 5 or something) - so everywhere that checked a message status also
got addended with an "AND unique_id != ''" clause and probably at some
later point someone looked at indexes in use and added unique_id to
a lot of them.
--
Jesse Norell
[EMAIL PROTECTED] is not my email address;
change "administrator" to my first name.
--
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
--
________________________________________________________________
Paul Stevens mailto:[EMAIL PROTECTED]
NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED]
The Netherlands________________________________http://www.nfg.nl
