-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Replication, Storage
-
None
-
Fully Compatible
-
ALL
-
v4.4, v4.2
-
Repl 2020-05-18
-
50
SERVER-41766 changed the catalog multikey update for multi-statement transactions on primaries to happen in a side transaction. This side transaction looks at the logical clock to find a timestamp far enough in the future to use for writing to the catalog.
Because (I believe) we only perform this ghost timestamp on primaries, it's preferable to instead write a no-op oplog entry. That way the stable timestamp never races with the transaction being committed. Durable history may have different consequences due to these races.
- is related to
-
SERVER-42251 Cannot timestamp multikey write during recovery of prepared transaction before LogicalClock has been initialized
- Closed
-
SERVER-46229 setting multikey on index fails if index was created within same multi-document transaction
- Closed
-
SERVER-49949 Reconstructing prepared transactions containing multi-key writes crashes the initial syncing node.
- Closed
-
SERVER-47867 Remove ghost timestamping code
- Closed
-
SERVER-48024 Have validate compare collection object with on-disk metadata object
- Closed
- related to
-
SERVER-48465 restore noop write msg format for single-phase index builds
- Closed