Follower layered cursor does not advance off the current key on the first next()/prev() after committing a read-timestamp transaction

XMLWordPrintableJSON

    • 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.

            Assignee:
            [DO NOT USE] Backlog - Storage Engines Team
            Reporter:
            Ivan Kochin
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: