https://bugs.openldap.org/show_bug.cgi?id=9842
Issue ID: 9842 Summary: Page should not be spilled if MDB_RESERVE is used Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs@openldap.org Reporter: stephan.j.bircher@gmail.com Target Milestone: ---
The documentation for the function mdb_cursor_put states for MDB_RESERVE the following: "return a pointer to the reserved space, which the caller can fill in later". However this seems only to be valid if no other operation is performed on the cursor. Once the cursor is moved the page where the reserved data resides on might become untracked and therefore eligible to be spilled at any time. This problems occurrs however only for large transactions where lmdb starts to spill and flush pages.
I'm using only lmdb and I'm a bit confused as the branches master (https://git.openldap.org/openldap/openldap/-/tree/master/libraries/liblmdb) and mdb.master (https://git.openldap.org/openldap/openldap/-/tree/mdb.master/libraries/liblm...) are not the same. For example the function mdb_pages_xkeep differs and master and mdb.master. Will the branches be consolidated again?
https://bugs.openldap.org/show_bug.cgi?id=9842
--- Comment #1 from Howard Chu hyc@openldap.org --- (In reply to stephan.j.bircher from comment #0)
The documentation for the function mdb_cursor_put states for MDB_RESERVE the following: "return a pointer to the reserved space, which the caller can fill in later". However this seems only to be valid if no other operation is performed on the cursor. Once the cursor is moved the page where the reserved data resides on might become untracked and therefore eligible to be spilled at any time.
True. Any data pointed to by a cursor is only valid while the cursor points to it. There's no bug here.
https://bugs.openldap.org/show_bug.cgi?id=9842
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
--- Comment #2 from Quanah Gibson-Mount quanah@openldap.org --- (In reply to stephan.j.bircher from comment #0)
I'm using only lmdb and I'm a bit confused as the branches master (https://git.openldap.org/openldap/openldap/-/tree/master/libraries/liblmdb) and mdb.master (https://git.openldap.org/openldap/openldap/-/tree/mdb.master/libraries/ liblmdb) are not the same. For example the function mdb_pages_xkeep differs and master and mdb.master. Will the branches be consolidated again?
The openldap/openldap/master tree is what's used by the OpenLDAP software, which is generally whatever the current LMDB release is.
The development branch for LMDB is the mdb.master branch
The current release branch for LMDB is mdb.RE/0.9 branch
https://bugs.openldap.org/show_bug.cgi?id=9842
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|needs_review | Status|RESOLVED |VERIFIED
https://bugs.openldap.org/show_bug.cgi?id=9842
--- Comment #3 from stephan.j.bircher@gmail.com --- (In reply to Howard Chu from comment #1)
(In reply to stephan.j.bircher from comment #0)
The documentation for the function mdb_cursor_put states for MDB_RESERVE the following: "return a pointer to the reserved space, which the caller can fill in later". However this seems only to be valid if no other operation is performed on the cursor. Once the cursor is moved the page where the reserved data resides on might become untracked and therefore eligible to be spilled at any time.
True. Any data pointed to by a cursor is only valid while the cursor points to it. There's no bug here.
Thank you for confirming. Maybe a small note for clarification in the documentation would help as "fill in later" is not that obvious. One as I did could think the data could be filled in as long as the transaction is open. My code actually was based on that assumption and all went fine until the transaction became bigger.