-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Concurrency
-
None
-
Fully Compatible
-
ALL
-
v4.4, v4.2, v4.0
-
Execution Team 2020-03-23, Execution Team 2020-04-06, Execution Team 2020-05-04, Execution Team 2020-05-18
-
(copied to CRM)
-
0
When we acquire collection locks with AutoGetCollectionForRead on a secondary, we set the TimestampReadSource on the recovery unit to kLastApplied if we were a secondary at the time. However, when we re-acquire locks after a yield in PlanExecutor, we use the same TimestampReadSource we had when we originally acquired those locks, even we've become a primary since. This is bad for the oplog specifically, because on a primary, the last applied time is not oplog-hole-free, meaning we can read past oplog holes. More in general, we should not read at a PIT if there are still write transactions that may commit at that PIT.
Suggested fix: Have secondary reads use the kNoOverlap read source instead of kLastApplied, which is std::min(*lastApplied, allDurable). This is the same as kLastApplied while a node is remains secondary, but is equivalent to kAllDurableSnapshot after transition to primary.
- is depended on by
-
SERVER-44529 Re-acquiring locks after a yield and step down results in wrong parameters on recoveryUnit
- Closed
- is related to
-
SERVER-48518 Rollback via refetch (EMRC = false) can make readers to see the rolled back data even after the rollback node catches up to primary.
- Closed
-
SERVER-47084 Support AutoGetCollectionForRead-like readSource validation after query yielding
- Closed
-
SERVER-48475 Secondary reads always calculate all_durable despite only using lastApplied
- Closed
- related to
-
SERVER-49781 Setting lastApplied before startup recovery has finished causes race with reconstructing prepared transactions
- Closed