CollectionCatalog may invariant in presence of a PIT read concurrent with a drop

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Catalog and Routing
    • ALL
    • 🟦 Shard Catalog
    • None
    • None
    • None
    • None
    • None
    • None

      As part of implementing SERVER-109829 the following race condition was observed:

      • Suppose an operation commits a drop at T=10. The WT operation commits but is pending publication of the changes to the catalog.
      • Before the change can be published a lock-free PIT for T=11 read comes in and registers that the collection exists at T=11. This can happen because the PIT read detects that the collection is pending some commits and has to recover from disk.
      • The drop now proceeds and finds the following invariant false since 11 > 10

      The conditions to hit this in production are quite small since PIT reads implictly wait until the provided timestamp is majority available, which means that the chosen timestamp should be less than the one used by the drop unless the drop was majority replicated to all other nodes as well.

            Assignee:
            Unassigned
            Reporter:
            Jordi Olivares Provencio
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: