-
Type: Bug
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: APIs
-
Storage Engines
-
StorEng - Defined Pipeline
Cursors that are cached are linked into the cursor cache at &session->cursor_cache[bucket]. Cursors that are not cached are linked into the session at &session->cursors. There are two functions that link a cursor into a session: __ wt_cursor_init() for newly created cursors, and __ wt_cursor_reopen() for cursors found in the cursor_cache and reused. __ wt_cursor_init() links the cursor after the owner cursor if the cursor has an owner, and at the head if the cursor does not have an owner. It has the comment: "Cursors that are internal to some other cursor (such as file cursors inside a table cursor) should be closed after the containing cursor. Arrange for that to happen by putting internal cursors after their owners on the queue." In contrast, __ wt_cursor_reopen() always links the cursor at the head. Thus a cursor that has been reopened can be closed in the wrong order.
- is related to
-
WT-12249 Opening a cursor may accidentally inherit config from a cached cursor
- Closed