Re: (ITS#7774) LMDB assertion failure during Postfix cache cleanup

[wietse@porcupine.org]

Hallvard Breien Furuseth:
> > Sofar the abstraction layer already hides the LMDB-specific MAP_FULL
> > and MAP_RESIZED error conditions. If this abstraction layer needs
> > additional code in order to maintain MDB cursor sanity, then please
> > educate me. 
> 
> ldmb.h says --
> 
> mdb_env_set_mapsize():
>     "It may be called at later times if no transactions are active in
>     this process. Note that the library does not check for this condition,
>     the caller must ensure it explicitly."
> MDB_NOLOCK:
>     "[caller] must ensure that no readers are using old transactions
>     while a writer is active. The simplest approach is to use an
>     exclusive lock so that no readers may be active at all when a writer
>     begins."
> 
> That's why I talked about saving the cursor position and restoring it -
> cursors are per-transaction and you need a new transaction.

I can remember the last key from mdb_cursor_get() and set the cursor
to that key. There does not appear to be a cursor "save" operation
in the API documentation http://symas.com/mdb/doc/group__mdb.html.

> Maybe you should have a single write-transaction with several cursors,
> instead of several transactions.  That also cures the "long-lived reader"
> problem.

That would result in delayed delete operations, and break correctness.
If a database entry is updated after it is scheduled for delete,
then the entry must not be deleted.

Also, I am concerned that would pollute my database-neutral API
with LMDB-specific details.

	Wietse

> Howard, maybe NOLOCK should keep the reader table and just drop the
> locks?  More work though.
> 
> -- 
> Hallvard