[Date Prev][Date Next]
Re: LMDB: question about MDB_RESERVE
Bryan Matsuo wrote:
I believe the documentation is making a more general statement. Yes, a
subsequent "put" invalidates the MDB_RESERVE pointer. But, beyond "put", "del"
operations will invalidate the destination pointer. In general, it's probably
safest to assume that an "update operation" is any operation that must take
place inside an update transaction (one that is not readonly).
My point of view on the library is that failing to obey its documented
operational requirements means all bets are off. Assume database corruption
will occur. And be happy if that isn't actually the case. Because the effect
is undocumented it may change between releases and you cannot rely on it. You
don't want to get stuck on an old library version because of reliance on
undefined behavior. Undefined behavior may not even be portable between
operating systems because of platform specific function implementations.
I hope this helps. I think the documentation is probably accurate enough. Like
the other docs, it is terse and merely requires a careful, literal reading. If
"get" operations were to invalidate the MDB_RESERVE pointer than I think the
docs would need to be changed. But my intuition makes me doubt that is the case.
On Sun, Dec 20, 2015 at 2:15 PM Christian Sell <firstname.lastname@example.org
I have a question about the MDB_RESERVE flag. The documentation in some places
says "reserve space for data of the given size, but don't copy the given data.
Instead, return a pointer to the reserved space, which the caller can fill in
later - before the next update operation or the transaction ends."
My question is specifically about the "before the next update operation or the
transaction ends" part. Does this mean the reserved buffer becomes unusable as
soon as another put is executed? What exactly happens? This statement does not
appear consistently, which is why I am doubting..
Where is the MDB_RESERVE doc inconsistent? Point it out and we'll clarify it.
thanks + happy holidays,
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/