Investigate a durable design for the ingest prune timestamp calculation

    • Type: Task
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: DHandles
    • None
    • Storage Engines - Foundations
    • 26.874
    • None
    • None

      Background

      WT-18532 fixed a follower stale read where a timestamped reader could bind a superseded checkpoint after the ingest content covering it had been pruned. The fix is short term: the reader publishes session_inuse, issues a full barrier, re-checks WT_DHANDLE_OUTDATED, and re-acquires the handle if it moved.

      Why it is short term

      The fix is fragile. It makes correctness depend on an implicit contract between dhandle->session_inuse and WT_DHANDLE_OUTDATED – two fields owned by different subsystems, one serving handle lifetime and the other GC pacing – held together by memory ordering rather than by any synchronising primitive. Every current and future path that acquires a checkpoint dhandle carries the obligation to re-validate; a site that forgets silently reintroduces a stale read, with no assertion or crash to surface it.

      Scope

      Find a design for the ingest prune timestamp calculation that establishes the invariant structurally rather than by detection and retry, and that does not couple the prune accounting to the dhandle flag lifecycle.

      The options considered so far, with their trade-offs, are in the comments of WT-18532. Option B there (treat handle existence as the pin) was ruled out because it ties GC progress to sweep cadence.

      Two candidates remain open:

      • alexander.gorrod@mongodb.com's proposal: "the prune timestamp is calculated by scanning open sessions, rather than dhandles. Each session would publish the prune timestamp it requires, and a scanning thread would review published prune timestamps and calculate the oldest necessary in the system (that goes along with a base value that keeps the calculation correct if there are no sessions, or it is possible for a new session to start and require an older prune timestamp). That is the approach used by pinned timestamp and other global timestamp tracking."
      • My idea I haven't thought deeply about - extending WT_GEN_DISAGG_CKPT to timestamped readers. WT-18156 built the generation pin, the validate-and-retry loop and the deferred-adoption machinery, but deliberately excluded timestamped readers on the grounds that the history store keeps them consistent. WT-18532 shows that reasoning does not hold once ingest pruning is in play, so the existing machinery may extend to cover this case.

      Neither has been analysed in depth. Other approaches may exist and should be considered before committing to one.

            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: