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.
- is related to
-
SERVER-84723 Sharded multi-document transactions can observe partial effects of concurrent DDL operations
- Closed
-
SERVER-84760 Violation of transaction snapshot isolation when collection concurrently dropped
- Closed
-
SERVER-89654 Port test introduced on SERVER-88746 to master
- Closed