Christian, 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. Cheers, - Bryan On Sun, Dec 20, 2015 at 2:15 PM Christian Sell <[email protected]> wrote: > Hello all, > > 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.. > > thanks + happy holidays, > Chris > >
