-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 4.1.4
-
Component/s: Querying, Replication
-
None
-
Fully Compatible
-
ALL
-
-
Repl 2019-01-14, Repl 2019-02-11, Repl 2019-02-25
When a cursor is opened with "linearizable" read concern, we guarantee that any data returned will reflect all successful majority-acknowledged writes that completed prior to the start of the read operation. If we do subsequent getMore operations on this cursor, however, we do not satisfy this linearizability guarantee.
I believe this bug is caused by the fact that when we wait for linearizable read concern here, we check the read concern arguments on the OperationContext of the running command. getMore commands, however, do not include a read concern directly. Their read concern is stored on the cursor object they are associated with. Since we only check the read concern from the OperationContext, we will presumably just return local read concern, bypassing the logic to satisfy the linearizability guarantee.
- is related to
-
SERVER-72896 Linearizable readConcern timeout for getMore is not configurable to values other than 15 seconds
- Closed
- related to
-
SERVER-39364 Audit uses of setLastOpToSystemLastOpTime
- Closed