-
Type: Bug
-
Resolution: Gone away
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Storage
-
Labels:None
-
ALL
-
Execution Team 2019-11-04
When in waitForAllEarlierOplogWritesToBeVisible, the method first records the "oplog read timestamp": https://github.com/mongodb/mongo/blob/43b018194e1a49249092b871f3b7396e473d1426/src/mongo/db/storage/wiredtiger/wiredtiger_oplog_manager.cpp#L82-L84
Every iteration of the wait-loop will compare this recorded value with a current reading. If that value goes backwards, that signals a rollback happened, which breaks out of the wait loop:
https://github.com/mongodb/mongo/blob/43b018194e1a49249092b871f3b7396e473d1426/src/mongo/db/storage/wiredtiger/wiredtiger_oplog_manager.cpp#L102-L109
However, because those values are just timestamps and not OpTimes (which contain terms), it's possible for a rollback to not be detected. For example, consider the "oplog read timestamp" starting at 10 and the method is waiting for time 15 to become visible. During one wait of the condition variable, it's possible the "oplog read timestamp" to advance to time 13, followed by a rollback that sets the time back to 11. Thus the rollback would not be detected.
I don't believe this is a matter of correctness; I expect callers must be doing rollback detection (or alternatively, operation contexts waiting on a condition variable may be getting signaled on rollback in a way that throws an exception?).
This is just a matter of liveness. In a typical case, the timestamp the reader is waiting to become visible is already committed and the system is just waiting for earlier holes (i.e: concurrent, in progress transactions) to be resolved.
With the code as it is, in the case of a rollback, the history up to the previous "oplog read timestamp" is destroyed. The liveness guarantee of this wait for the now defunct "oplog read timestamp" is predicated on new activity coming into the system.