Validate a pending DROP before panicking on skipped shared metadata creates

XMLWordPrintableJSON

    • Type: Task
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Layered Tables
    • None
    • Storage Engines - Foundations
    • 562.812
    • None
    • None

      There are now two distinct reasons a CREATE entry can be left parked when processing the shared metadata queue: the connection is in the step-down window, or the stable schema epoch falls between the CREATE and DROP epochs of the same table.

      The second case ends in a panic. Before panicking, the code should confirm that a pending DROP for the same URI really does appear later in the queue, and the error message should report that DROP's epoch. That both distinguishes the two causes and makes the reported API violation actionable.

      See the FIXME in __wt_disagg_shared_metadata_queue_process (src/conn/conn_layered.c).

            Assignee:
            Alex Blekhman
            Reporter:
            Jie Chen
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: