[PATCH] LMDB full patch set

[Howard Chu]

Andrew Bartlett wrote:
> On Mon, 2018-04-16 at 16:57 +0100, Howard Chu wrote:
>> mdb_env_close() will reset any reader slots owned by the process. The PID is
>> stored in env->me_pid so unfortunately both parent and child will have the
>> same PID recorded here after a fork. Thus env_close in the child would end up
>> releasing the parent's reader slots. Fairly disastrous. Obviously we can fix
>> this trivially by just using getpid() in env_close().
> 
> So, if after the fork(), we just ignore the old DB, except to close
> mdb_env_get_fd() (which is not the lock file, and so has no fcntl
> semantics) are we safe?

Safe, yes. But you could also just merge in this patch now
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=tree;f=libraries/liblmdb;hb=3b01bbbc67389b63e6623da99d397283729e70e7

which makes mdb_env_close() safe, as mentioned above.

> I know we will leak a little memory, but as we don't create a deep tree
> (sometimes a wide one, but never more than about 3 deep), we can cope
> with that.
> 
> Then, when the re-open behaviour becomes available in a release we can
> consider using that.
> 
> Would this be safe?  (It seems safe from our tests so far).
> 
> Thanks,
> 
> Andrew Bartlett
> 


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/