By accident. Note that LMDB 1.0 supports page checksums, and what you're doing here
will break those checksums.
Will the checksums be mandatory or optional? For InMemory/NoSync case they could add overhead and you already have many options to choose safety vs performance (WRITEMAP, NOMETASYNC, etc).
In-place updates in write transactions are 2x faster and work from several threads, it's just a lock and cumulative performance over N threads behaves just as with a shared lock.
For some reason, in-place updates from read transactions
work for NoSync case (with 1M 16-bytes values in tests) and give another 2x performance. Yet I understand the ludicrosity of such attempts.
Basically you're abusing MDB_WRITEMAP, whose only purpose is to (potentially) optimize
normal write transactions. I've no interest in even speculating on intentional misuse
of the API.
I successfully use
the overflow-pages-do-not-move hack
and already rely on it (since it was confirmed in this thread that at least for a particular version large pages do not move by design). LMDB acts like a shared memory allocator/pool, to move buffers off-heap and make them accessible from different processes and containers. Checksums will break this case as well, but I'm fine staying with 0.9x because it's too cool to have 500G NVM
fast granular random-access memory pool with only 16G RAM on the smallest AWS i3 instance and similar cases. But still having checksums optional would be nice, I already use ones at application level.