-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Critical - P2
-
Affects Version/s: 6.0.0, 5.0.10, 6.1.0-rc1
-
Component/s: None
-
None
-
Fully Compatible
-
ALL
-
v6.1
-
-
Execution Team 2022-07-25, Execution Team 2022-08-08, Execution Team 2022-08-22, Execution Team 2022-09-05
-
100
-
None
-
None
-
None
-
None
-
None
-
None
-
None
In the following scenario:
- Multi-doc transaction starts, reading from a snapshot @ timestamp (9,1).
- (10,1): index build on collection A completes.
- (11,1): transaction writes to collection A, which involves updating the index that was built at (10, 1).
At step 3 the transaction doesn't fail with SnapshotUnavailable code name + TransientTransactionError label + "Unable to read from a snapshot due to pending collection catalog changes; please retry the operation" message.
This is a bug that opens the opportunity for a race condition to happen, which can result in data inconsistency as the index key won't get updated.
Adding _indexCatalogEntry->isReady(opCtx) in _indexKeysOrWriteToSideTable resolves the issue: step 3 fails with SnapshotUnavailable, instead of silently progressing with an invalid, stale snapshot.
- is related to
-
SERVER-68573 Remove special handling in index code that handles index to be out-of-sync with snapshot
-
- Closed
-
-
SERVER-47866 Secondary readers do not need to reacquire PBWM lock if there are catalog conflicts
-
- Closed
-
-
SERVER-68455 Clean up and publish GDB helpers for dumping in-memory representation of WT tables
-
- Closed
-