Use atomic accesses for layered_table_manager.leader

XMLWordPrintableJSON

    • Storage Engines - Foundations
    • 317.52
    • SE Foundations - 2026-08-18
    • 1

      conn->layered_table_manager.leader is a plain bool, written on role reconfigure (step-up/step-down in conn_layered.c) and read without synchronization from ~50 sites across the tree (layered cursor routing, checkpoint, eviction, history store, schema, sweep).

      Until now the role effectively only changed while the system was quiesced. With asynchronous step-down and step-up the reconfigure runs concurrently with application cursor traffic, so these plain stores/loads are a data race under the C memory model (TSan would report it).

      Relaxed atomics are sufficient: the ordering that matters is provided by the step-down lock around the step-down timestamp, not by this flag. A reader can still observe a stale role across the transition; layered cursor operations tolerate that because a transaction that began with the step-down timestamp set routes to the ingest constituent regardless of the role it observes.

      Scope:
      - Mark the field wt_shared in WT_LAYERED_TABLE_MANAGER (connection.h) and document the contract: who writes it, that readers may see a stale value, and why that is tolerated.
      - Convert the writes and reads to __wt_atomic_store_bool_relaxed / __wt_atomic_load_bool_relaxed.
      - Audit non-cursor readers (checkpoint, sweep, history store asserts, schema) for whether a stale value is tolerable in their context.

            Assignee:
            Sid Mahajan
            Reporter:
            Sid Mahajan
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: