[PATCH] LMDB full patch set

[Howard Chu]

Andrew Bartlett wrote:
> On Thu, 2018-05-03 at 15:16 +0100, Howard Chu wrote:
>> 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.
> 
> OK.  At this stage we were not planning on bundling lmdb into
> third_party or vendoring it into Samba so we can't rely on recent
> fixes, but once there is a released version with this in we can call
> that within an #ifdef guard.  (bonus points if some CPP macro declares
> it safe).

Next release probably in a couple weeks.

But not bundling makes no sense to me, you won't have MDB_VL32 support on 
32bit builds. As I recall, 32bit support was the main reason we started this 
conversation however-many-years ago.
> 
> A reopen would still be nice because then we could match tdb where
> would not need a new FD and so can't run out of FDs or have files go
> missing under our feet.

OK, we can implement the mdb_env_postfork() API I described earlier.
> 
> 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/