Details
-
Improvement
-
Status: Backlog
-
Major - P3
-
Resolution: Unresolved
-
None
-
None
-
None
-
Storage Execution
Description
It can be convenient to allow MDB nodes to allow inserts into the oplog (and is even necessary for some current restore procedures). But oplog entries being inserted with a bad (stale) timestamp trip this fassert.
The fassert is important for correctness of the typical writes replication performs against the oplog (that are still on behalf of a user operation). But there is hopefully a path for validating these timestamps.
Perhaps a strict validation that an oplog entry's ts field is larger than the current top of oplog? With an exception for an explicit `ts: Timestamp(0, 0)` as I expect the server to be choosing TopOfOplog + 1.
Attachments
Issue Links
- duplicates
-
SERVER-48637 error:WiredTiger error (22) and Fatal assertion 39001
-
- Closed
-
- is related to
-
SERVER-67790 [4.2] Running with enableMajorityReadConcern=false can commit behind the oldest/stable timestamp
-
- Closed
-
-
-
- Closed
-