-
Type:
Task
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Storage Execution
-
Storage Execution 2026-03-16, Storage Execution 2026-04-13
-
None
-
None
-
None
-
None
-
None
-
None
-
None
There exist processes such as SERVER-120400 where we assume the order of operations however when batching is enabled, the timestamp of an operation is deferred until commit. If there is a set of operations that mixes DDL with non-DDL operations such that the non-DDL operation is intended to have an earlier timestamp, we may see a bug where because it is now batched (and the DDL was not) that the order of these operations change.
We should investigate where else this bug may exist.
- depends on
-
SERVER-122019 Handle getNextOpTimes in cloneCollectionAsCapped for PDIB
-
- Closed
-
-
SERVER-122020 Handle getNextOpTimes in UpsertStage::_performInsert for PDIB
-
- Closed
-
-
SERVER-122021 Handle getNextOpTimes in acquireOplogSlotsForInserts for PDIB
-
- Closed
-
-
SERVER-122022 Handle getNextOpTimes in resharding::data_copy::insertBatch for PDIB
-
- Closed
-
-
SERVER-122023 Handle getNextOpTime in DatabaseImpl::_createCollection for PDIB
-
- Closed
-
-
SERVER-122024 Handle getNextOpTimes in copySourceToTemporaryCollectionOnTargetDB for PDIB
-
- Closed
-
-
SERVER-122383 Handle getNextOpTimes in repl::applyOperation_inlock for PDIB
-
- Closed
-
- is related to
-
SERVER-120400 Primary-driven index build attempting to insert duplicate config.system.indexBuilds entry on secondary
-
- Closed
-
-
SERVER-121960 Make WriteUnitOfWork::_isGroupingOplogEntries public
-
- Closed
-
-
SERVER-122321 Ensure that no timestamp was previously set when committing batched write
-
- Closed
-
- related to
-
SERVER-121646 Timestamp for reserving pre-images for find and modify are not guaranteed to be T-1
-
- Closed
-
-
SERVER-120903 update TODO comments for SERVER-120074 to refer to SERVER-120623
-
- Closed
-