More Skiplist Stuff!

Bron Gondwana brong at fastmail.fm
Thu Jan 10 17:23:30 EST 2008


On Thu, Jan 10, 2008 at 05:00:55PM +0000, David Carter wrote:
> On Wed, 2 Jan 2008, Bron Gondwana wrote:
>
>> The renewed one is:
>> http://cyrus.brong.fastmail.fm/patches/cyrus-skiplist-transactions-2.3.10.diff
>>
>> This didn't apply when I was building 2.3.11, and stupid me went "ahh, Ken 
>> must have accepted it since it's really quite important to have something 
>> like this".  Gosh.  No wonder our mailboxes.db reliability has been 
>> dropping off again.
>
> This one still seems to be outstanding. Is it now obsolete given:
>
>> The new one is what found this, and is the _real_ solution to lock
>> safety - code that asserts that the locking status of the file is
>> what we expect it to be by tracking both the lock status and an
>> is_open allowing us to re-read the entire header safely in each
>> locking function.
>>
>> http://cyrus.brong.fastmail.fm/patches/cyrus-skiplist-state-2.3.11.diff
>>
>> I haven't put a description on this one, but it's reasonably clear
>> from the code I hope.
>
> which was merged earlier this week?

Sort of - it will cause an abort() if your code is silly enough to try
and make an untransactioned read while another transaction is active.

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

Bron.


More information about the Cyrus-devel mailing list