Victor Baybekov wrote:
Hello,
Working with overflow pages directly via pointers outside write transactions works great and it helps that they do not move "by design" in current versions as discussed in this thread.
I have two related scenarios that will give a substantial performance boost in my case.
/The first one/ is updating a value in-place via pointer from aborted write transaction. If I
- use MDB_WRITEMAP,
- from **write** transaction find a record (which is small and not in an overflow page),
- modify a part of it's value (for duplicates this part is not used in the compare function) directly via the MDB_VAL data pointer (e.g. interlocked_increment
or compare_and_swap), 4) and **abort** the transaction,
then readers see the updated value via normal read transactions later. Since I do the direct updates from inside a write transaction all other writers should be locked until I exit the transaction (abort in this case), and no pages should move since the transaction is aborted. Is this correct? Does this work "by design" or "by accident" currently?
By accident. Note that LMDB 1.0 supports page checksums, and what you're doing here will break those checksums.
/The second one/ is about updating values in-place from read transactions. If I
Updating any value in a read transaction is ludicrous.
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.