R: More Skiplist Stuff!
Pietro.Toschi at actalis.it
Tue Jan 15 05:59:53 EST 2008
I'm afraid to bother on the devel list since I'm not a developer, but I've got some confusion about what patches should I apply to a fresh 2.3.11 cyrus-imapd tarball in order to have a not-broken skiplist mailboxes.db (and possibly all the remaining backends too) and avoid those problematic DB ERRORS and reconstruct?
Would you be so kind and please summarize and put some light about the correct patching-path that we (simply humans) should follow (possibly before your escape to the Tasmanian bushes, Bron :-))
Thank in advance.
Da: cyrus-devel-bounces at lists.andrew.cmu.edu [mailto:cyrus-devel-bounces at lists.andrew.cmu.edu] Per conto di David Carter
Inviato: venerdì 11 gennaio 2008 14.47
A: Bron Gondwana
Cc: cyrus-devel at lists.andrew.cmu.edu
Oggetto: Re: More Skiplist Stuff!
On Fri, 11 Jan 2008, Bron Gondwana wrote:
> The better alternative to this patch would be to rewrite the fast_rename
> and folder_limit patches to not do untransactioned reads in the middle
> of a transaction, but that involves API changes to a few functions so
> that the transaction will be passed around.
fast_rename doesn't seem to do this: the two mboxlist_count_inferiors()
calls fall between a DB->commit and the following DB->delete and
DB->store. I guess this is why I haven't been having problems. Phew.
folder_limit does have a problem as mboxlist_mycreatemailboxcheck() is
used in the middle of a transaction in mboxlist_renamemailbox(), maybe
other places as well. I think that my approach would be to move the folder
limit test into imapd.c, cmd_create(). I think that's the only place where
end users can create new mailboxes without one of the autocreate patches.
> Either that or just create a global "struct txn *mailboxesdb_txn" or
> something and use that. Pretty icky either way, but at least it won't
> break on berkeley mailboxes_db.
Does the Berkeley backend deadlock if you start an DB->foreach in the
middle of a transaction? That would be a pain. I did like your idea of
reusing the existing transaction/lock if the caller didn't specify one.
David Carter Email: David.Carter at ucs.cam.ac.uk
University Computing Service, Phone: (01223) 334502
New Museums Site, Pembroke Street, Fax: (01223) 334679
Cambridge UK. CB2 3QH.
More information about the Cyrus-devel