Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-88746

[v7.0] Writes in transactions in replica sets may not conflict with collection drop and rename, violating snapshot isolation

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Critical - P2 Critical - P2
    • 7.0.10
    • Affects Version/s: 7.0.0
    • Component/s: Catalog
    • None
    • Catalog and Routing
    • Fully Compatible
    • ALL
    • CAR Team 2024-04-15, CAR Team 2024-04-29
    • 200

      Collection acquisitions from the shard role API (7.1 and later) call CollectionCatalog::establishConsistentCollection() both when the namespace is being used for writes and when the namespace is being used for reads. In 7.0, CollectionCatalog::establishConsistentCollection() is only used for reads. This means if the collection doesn't exist at the wall-clock time of the transaction beginning but the collection did originally exist at the read timestamp of the transaction, then attempting to write to the collection namespace won't error. This leads to violations of snapshot isolation in scenarios similar to SERVER-84760 but where writes (e.g. findAndModify) are impacted.

      If the collection is read within the transaction prior to attempting to write to the collection, then attempting to write to the collection will correctly error when interleaved with a drop or rename.

      This only affects replica sets, as SERVER-84723 tightened the acquisition conditions on sharding clusters in a way that prevents this bug from manifesting.

      In 6.0 and earlier, attempting to read or write to a collection which was re-created would cause the transaction to correctly error.

            Assignee:
            jordi.serra-torrens@mongodb.com Jordi Serra Torrens
            Reporter:
            max.hirschhorn@mongodb.com Max Hirschhorn
            Votes:
            0 Vote for this issue
            Watchers:
            13 Start watching this issue

              Created:
              Updated:
              Resolved: