Re: (ITS#7774) LMDB assertion failure during Postfix cache cleanup
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