[SERVER-39199] Committing or aborting a prepared transaction may not un-pin stable timestamp due to oplog hole Created: 25/Jan/19 Updated: 29/Oct/23 Resolved: 04/Feb/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.8 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Judah Schvimer | Assignee: | Judah Schvimer |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | prepare_durability | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Steps To Reproduce: | This can be reproduced by making this diff on bbe09aa5e0966ada5232ffbcb098efdd78b4f24e:
And running:
|
||||||||||||||||
| Sprint: | Repl 2019-02-11 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Linked BF Score: | 7 | ||||||||||||||||
| Description |
|
If we recalculate the stable timestamp after we commit the transaction, write the commit oplog entry, and update the metrics, but before we close the oplog hole, then we may never recalculate it after the oplog hole actually closes. This does not go away when we stop pinning the stable timestamp back. This is due to the OplogSlotReserver holding open an oplog hole past where we recalculate the stable timestamp. |
| Comments |
| Comment by Githook User [ 04/Feb/19 ] |
|
Author: {'name': 'Judah Schvimer', 'email': 'judah@mongodb.com', 'username': 'judahschvimer'}Message: |
| Comment by Judah Schvimer [ 25/Jan/19 ] |
|
We also are not currently telling storage about the new stable timestamp when we recalculate it, which means we do not advance the majority committed snapshot. |