> There was never a bug here. The doc is quite explicit
> 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.
And without MDB_VL32, plain cursor closing after txn abort seems to work
just fine (I did not consider "closing" as "using" when I read the docs).
One could say that the inconsistent behavior is a result of the complexity
If you don't want to change the current behavior, it would still be nice for
future developers to null the obsolete txn ptr in the cursor on txn abort to
make the unwanted close call crash always, not just occasionally.