-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Critical - P2
-
Affects Version/s: None
-
Component/s: Querying, Replication, Storage
-
Fully Compatible
-
ALL
-
Execution Team 2019-12-02, Execution Team 2019-12-16, Execution Team 2020-01-13, Execution Team 2020-01-27, Execution Team 2020-02-10, Execution Team 2019-12-30, Execution Team 2020-02-24, Execution Team 2020-03-09, Execution Team 2020-03-23, Execution Team 2020-04-06, Execution Team 2020-05-04, Execution Team 2020-05-18
-
13
-
None
-
0
-
None
-
None
-
None
-
None
-
None
-
None
When we acquire collection locks with AutoGetCollectionForRead on a primary, we by default set the TimestampReadSource on the recovery unit to kUnset. However, when we re-acquire locks after a yield in PlanExecutor, we still use that same TimestampReadSource even if we have stepped down. Since reads survive replication state changes, that can result in us reading from within the middle of a replication batch, which means reading possibly causally-related data out of order.
Note: This ticket initially described both step up and step down, but step up is now separated out into SERVER-46721.
Potential fix: After recovery from yield, change the read source to kNoOverlap if it was kUnset or kNoTimestamp.
- depends on
-
-
- Closed
-
- is related to
-
SERVER-47084 Support AutoGetCollectionForRead-like readSource validation after query yielding
-
- Closed
-
-
-
- Closed
-
- related to
-
-
- Closed
-