[SERVER-42251] Cannot timestamp multikey write during recovery of prepared transaction before LogicalClock has been initialized Created: 16/Jul/19 Updated: 29/Oct/23 Resolved: 23/Jul/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | 4.2.0-rc2 |
| Fix Version/s: | 4.2.0-rc5, 4.3.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | William Schultz (Inactive) | Assignee: | William Schultz (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||
| Backport Requested: |
v4.2
|
||||||||||||||||||||||||
| Sprint: | Repl 2019-07-29 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Linked BF Score: | 19 | ||||||||||||||||||||||||
| Description |
|
When reconstructing a prepared transaction during replication recovery, we try to timestamp a multikey write with a timestamp from the LogicalClock. The LogicalClock may not have been initialized yet, though, which leads to an error if we try to timestamp the write with a zero timestamp. A proposed solution is to instead propagate the prepare timestamp of the transaction into that codepath so that we can timestamp the write with the transaction's prepare timestamp. |
| Comments |
| Comment by Githook User [ 24/Jul/19 ] |
|
Author: {'name': 'William Schultz', 'email': 'william.schultz@mongodb.com', 'username': 'will62794'}Message: Now that we execute multikey catalog updates in a side transaction, we need to give them some suitable timestamp. In normal replication, we can grab the latest value of the LogicalClock. In startup recovery, though, we may replay a prepared transaction that does a multikey write, but the LogicalClock may not have been initialized yet. Thus, we use the prepare timestamp of the transaction for the multikey write, since that timestamp is guaranteed to be less than or equal to the commit timestamp of the transaction. (cherry picked from commit 7d687264de65258764dca70ce46754c4765912ce) |
| Comment by Githook User [ 23/Jul/19 ] |
|
Author: {'name': 'William Schultz', 'email': 'william.schultz@mongodb.com', 'username': 'will62794'}Message: Now that we execute multikey catalog updates in a side transaction, we need to give them some suitable timestamp. In normal replication, we can grab the latest value of the LogicalClock. In startup recovery, though, we may replay a prepared transaction that does a multikey write, but the LogicalClock may not have been initialized yet. Thus, we use the prepare timestamp of the transaction for the multikey write, since that timestamp is guaranteed to be less than or equal to the commit timestamp of the transaction. |
| Comment by William Schultz (Inactive) [ 22/Jul/19 ] |
|
Code review url: https://mongodbcr.appspot.com/502180013/ |