[SERVER-33859] Prime the oplog manager's visibility timestamp with the top of oplog Created: 13/Mar/18 Updated: 29/Oct/23 Resolved: 15/Mar/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | 3.7.4 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Daniel Gottlieb (Inactive) | Assignee: | Daniel Gottlieb (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | rollback-functional | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Operating System: | ALL | ||||
| Sprint: | Repl 2018-03-26 | ||||
| Participants: | |||||
| Linked BF Score: | 0 | ||||
| Description |
|
At startup, the `WiredTigerOplogManager::_oplogReadTimestamp` is typically initialized to `1`. Currently, oplog readers getting a visibility timestamp are completely asynchronous with how that value is updated; an oplog reader that gets in quickly after startup can attempt to read with timestamp 1 and crash the server. Instead, it should be legal to initialize the value with `_oplogMaxAtStartup`. That value may contain holes, but holes imply replication recovery will truncate the oplog before accepting connections. A call to `cappedTruncateAfter` will set the correct the value. |
| Comments |
| Comment by Githook User [ 14/Mar/18 ] |
|
Author: {'email': 'daniel.gottlieb@mongodb.com', 'name': 'Daniel Gottlieb', 'username': 'dgottlieb'}Message: |