[PATCH] LMDB full patch set
hyc at highlandsun.com
Thu May 3 19:07:34 UTC 2018
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
>> 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.
> 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/
More information about the samba-technical