https://bugs.openldap.org/show_bug.cgi?id=9397
--- Comment #7 from tina@tina.pm --- Hi,
I am the person who reported the original problem to Nic, after getting my DB corrupted the minute I started doing multiprocessing.
I wanted to comment on this:
(In reply to Howard Chu from comment #3)
1st: "Don't do that." The docs for mdb_env_mapsize() make it clear that it's up to the caller to ensure that no other txns are active at the time it is called. We can first expand this statement in the docs and say that the caller is responsible to ensure that no other *users* are active - processes, threads, txns, whatever.
I think that is far from clear in the documentation, and it seems to be many projects out there (including mine) doing dynamic resizing assuming that no other txns are active *in the current process*! I would urge you to update the documentation then, as this might be a DB corruption waiting to happen in many places.
Having said that, instead of delegating this to users, which would result in reinventing the wheel and falling for the many pitfalls of file locking across architectures, is there any good reason not to obtain an exclusive lock on the lock file when mdb_env_mapsize() is called?
Alternatively, would you consider offering in the API a exclusive locking function using the current mechanisms?
Thanks.