tdb1 has tdb_reopen/tdb_reopen_all, which you are supposed to call
after a fork(). But we can detect PID changes whenever we grab a lock,
which is to say, before we do anything.
We currently assume that pread and pwrite work, so the only problem
with fork() is if we are holding locks and expect them to still be
there in the child. This is unusual, but most likely caused by a
fork() inside a transaction. In such cases, allow the child to unlock
without complaint; they can then use the TDB as expected.
Performance before and after shows no measurable speed difference:
Total of 5 runs of tools/speed 100000:
Before:
Adding: 18899ns
Finding: 7040ns
Missing: 5802ns
Traversing: 6466ns
Deleting: 12607ns
Re-adding: 14185ns
Appending: 20770ns
Churning: 93845ns