Fix CollectionCatalog non-staleness assertion in rename collection op application

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Fixed
    • Priority: Major - P3
    • 8.2.0-rc0
    • Affects Version/s: 8.2.0-rc0
    • Component/s: Catalog
    • None
    • Catalog and Routing
    • Fully Compatible
    • ALL
    • CAR Team 2025-06-09
    • 0
    • None
    • 3
    • TBD
    • 🟦 Shard Catalog
    • None
    • None
    • None
    • None
    • None
    • None
    • 0

      SERVER-103744 introduced a debug assertion in acquireLocksForRenameCollectionWithinDBForApplyOps that CollectionCatalog::get(opCtx) == CollectionCatalog::latest(opCtx) to support the assumption that in that scenario CollectionCatalog::get(opCtx) can't return us an stale instance of the catalog (e.g. one that was stashed associated to an storage snapshot).

      However this assertion can fail because the drop-pending ident reaper can concurrently write to the catalog, so that each side of the assertion sees a different instance (even though neither instance was stale).

      We should change the assertion to check if there's an open storage snapshot instead.

              Assignee:
              Joan Bruguera Micó
              Reporter:
              Joan Bruguera Micó
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: