From: Howard Chu Date: Wed, 21 Aug 2013 00:37:53 +0000 (-0700) Subject: Update caveats now that mdb_reader_check exists X-Git-Tag: OPENLDAP_REL_ENG_2_4_37~39^2~20 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=c22a7d98ecac671b69faeef7d406cec4140b2abf;p=openldap Update caveats now that mdb_reader_check exists --- diff --git a/libraries/liblmdb/lmdb.h b/libraries/liblmdb/lmdb.h index 83f083d034..ef284d9c7e 100644 --- a/libraries/liblmdb/lmdb.h +++ b/libraries/liblmdb/lmdb.h @@ -48,8 +48,10 @@ * cause further writes to grow the database quickly, and * stale locks can block further operation. * - * Fix: Terminate all programs using the database, or make - * them close it. Next database user will reset the lockfile. + * Fix: Check for stale readers periodically, using the + * #mdb_reader_check function or the mdb_stat tool. Or just + * make all programs using the database close it; the lockfile + * is always reset on first open of the environment. * * - On BSD systems or others configured with MDB_USE_POSIX_SEM, * startup can fail due to semaphores owned by another userid. @@ -86,11 +88,12 @@ * ...when several processes can use a database concurrently: * * - Avoid aborting a process with an active transaction. - * The transaction becomes "long-lived" as above until the lockfile - * is reset, since the process may not remove it from the lockfile. + * The transaction becomes "long-lived" as above until a check + * for stale readers is performed or the lockfile is reset, + * since the process may not remove it from the lockfile. * - * - If you do that anyway, close the environment once in a while, - * so the lockfile can get reset. + * - If you do that anyway, do a periodic check for stale readers. Or + * close the environment once in a while, so the lockfile can get reset. * * - Do not use MDB databases on remote filesystems, even between * processes on the same host. This breaks flock() on some OSes,