Howard Chu wrote:
Markus Junginger wrote:
There was never a bug here. The doc is quite explicit http://www.lmdb.tech/doc/group__mdb.html#ga73a5938ae4c3239ee11efa07eb22b882
After txn_abort the only valid call on a still-open cursor is cursor_renew, not cursor_close.
However you want to call it, are you open to improve this workflow?
API-wise, it would be so much simpler just to free a cursor after it became obsolete. It's counter-intuitive to open a new txn, renew the cursor, close the cursor, and abort the txn - just to close a cursor.
API-wise, it is much simpler to just close the cursor before closing its transaction, if you have no need to reuse the cursor.
To be explicit - a typical workflow, as outlined in the Getting Started guide:
Open an env Open a txn inside the env Open a cursor inside the txn
When finished:
Close cursor inside txn Close txn inside env Close env
The only reason the API allows a read cursor to exist outside of its creating read txn is to allow it to be reused in a later read txn. If you're not reusing it then you should just close it in the proper order.