Details
-
Bug
-
Status: Closed
-
Major - P3
-
Resolution: Fixed
-
4.2.0, 4.4.0-rc0
-
Fully Compatible
-
ALL
-
v4.4, v4.2
-
Query 2020-08-24, Query 2020-09-07, Query 2020-09-21
-
33
Description
Because secondaries apply operations out of order, the following scenario can play out in the absence of special logic:
{op: "i", o: {_id: "A", a: [1,2]}, ts: Timestamp(1, 1)}}
|
{op: "i", o: {_id: "B", a: [1,2]}, ts: Timestamp(1, 2)}}
|
|
| Applier 1 | Applier 2 | Reader |
|
|----------------------+------------------------------+-------------------------------------------|
|
| Begin Txn | | |
|
| Write B | | |
|
| Update Indexes | | |
|
| Update Multikeypaths | | |
|
| TimestampTxn (1, 2) | | |
|
| Commit | | |
|
| | Begin Txn | |
|
| | Write A | |
|
| | Update Indexes | |
|
| | (No Multikeypaths to update) | |
|
| | TimestampTxn (1, 1) | |
|
| | Commit | |
|
| | | BeginTxn |
|
| | | ReadTimestamp (1,1) |
|
| | | Sees A |
|
| | | Does not see corresponding multikey paths |
|
See this comment for persisting classical index multikey paths.
Attachments
Issue Links
- related to
-
SERVER-56877 insert operations may fail to set index to multikey after aborted multikey catalog update
-
- Closed
-