-
Type:
Bug
-
Resolution: Duplicate
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Labels:None
-
ALL
-
Execution Team 2021-11-15
Suppose the document being inserted into a collection is of the form:
RecordId(1) -> X
and the logical key/value being inserted into the index is of the form:
KeyString(X) -> RecordId(1)
WT (non _id) unique indexes will make writes to two keys:
- KeyString(X) + RecordId(1)
- KeyString(X)
The first key is persisted (on a successful WT txn commit). The second key is deleted before committing. The purpose of the second key is to correctly maintain the unique index constraint in the face of concurrent transactions at snapshot isolation that can possibly observe write skew .
For primaries this works fine. For secondaries, we can process oplog entries out of order. This has a consequence for the common key two separate inserts can touch. Consider the following oplog entries being applied to collection with a unique index on x:
| Oplog |
|-------------------------------|
| Insert {_id: 1, x: 1} @ TS(1) |
| Delete {_id: 1} @ TS(2) |
| Insert {_id: 2, x: 1} @ TS(3) |
Those oplog entries can be applied with the following interleaving:
| Applier 1 | Applier 2 | |-----------------------------------+-----------------------------------| | | BeginTxn | | | SetTimestamp 3 | | | Insert KeyString(1) | | | Delete KeyString(1) | | | Insert KeyString(1) + RecordId(2) | | | Commit | | | | | BeginTxn | | | SetTimestamp 1 | | | Insert KeyString(1) | | | Delete KeyString(1) | | | Insert KeyString(1) + RecordId(1) | | | Commit | |
- duplicates
-
-
- Closed
-
- related to
-
SERVER-61521 Complete TODO listed in SERVER-60716
-
- Closed
-