R: More Skiplist Stuff!

[Toschi Pietro]

David, Bron,
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.
Pietro

-----Messaggio originale-----
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.