I think there's a problem with cursor iteration and limbo pages.
If we have a pinned page based on a cursor iteration, we discard the pinned page under some circumstances (the page is flagged for forced eviction or the page is in the WT_REF_LIMBO state). If we discard the pinned page, the actual key/value entry can be physically removed underneath the cursor, and we have lost the cursor's position. The next iteration will start at the beginning of the table, which is pretty bad.
We could skip the forced eviction check when using an iterating cursor, but limbo pages aren't so easy. I think we either have to always instantiate pages being read for an iterating cursor, or somehow swap the instantiated page into place without allowing entries to be removed (which sounds impossible).
michael.cahill, am I missing something?
- is depended on by
-
WT-3766 Lookaside sweep for obsolete updates
- Closed
-
WT-3805 Avoid reading lookaside pages in truncate fast path
- Closed
- is related to
-
WT-3835 cursor remove tries to return a key that doesn't exist
- Closed
-
WT-3769 Fix a bug in reverse cursor walks with particular delete patterns and prefix compression enabled
- Closed
- links to