[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
- From: hyc@symas.com
- Date: Fri, 09 Feb 2018 17:14:20 +0000
- Auto-submitted: auto-generated (OpenLDAP-ITS)
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/