[PATCH] LMDB full patch set

[Simo]

On Mon, 2018-04-16 at 14:36 +0200, Volker Lendecke via samba-technical
wrote:
> On Fri, Apr 13, 2018 at 07:00:35AM +1200, Andrew Bartlett via samba-technical wrote:
> > It seems so, and there isn't much we can do.  If you think about a
> > fork() based memory model then cleaning up the internal state will only
> > dirty memory anyway.  They don't provide a 'clean up after fork()'
> > function, but do strictly require that you not touch an environment
> > after a fork(). 
> 
> Asked Howard directly about fork handling. His reply contains:
> 
> > After discussing this on -devel IRC, I think we could add an
> > mdb_env_postfork() call that the child can use to make its copy of
> > the env valid. It would have the same restrictions as
> > mdb_env_set_mapsize() - there must not be any active txns in the
> > parent process at the time of fork - they'd just be memleaks in the
> > child. The child must call this immediately, and cannot call any
> > other LMDB APIs until this is done. But assuming those conditions
> > are met, we can continue to use the existing file descriptors and
> > mmaps without needing to tear down and reopen.
> 
> Would that help us?

It would require to gate forks on the fact no transactions are open.
Can we guarantee no transactions in parents or block forks?

Note: If we need to fork a utility within the transaction we do not
need to gate it as long as we have call semantics that enforce an exec
or a panic I guess.

Simo.