-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Layered Tables
-
Storage Engines - Foundations
-
339.311
-
None
-
None
On a disaggregated follower, a layered-table cursor is positioned on a key inside a transaction that reads with a read_timestamp in the past, and that transaction is then committed while the cursor stays open and positioned. The key the cursor is on still exists at the latest time.
The first next() / prev() after the commit does not move to a neighbouring key — it returns the same key the cursor was already on (with that key's latest value).
Expected: after the commit, next()/prev() must step to the neighbouring key, identically to a regular (non-layered) table cursor — prev() returns the next-smaller key and next() the next-larger key.