[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:
Backports
Depends
Related
related to SERVER-48010 Substitute ghost timestamp with no-op... Closed
is related to SERVER-49949 Reconstructing prepared transactions ... Closed
is related to SERVER-53932 Multikey write during recovery of pre... Closed
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: SERVER-42251 Timestamp multikey writes with the prepare timestamp during replication recovery

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)
Branch: v4.2
https://github.com/mongodb/mongo/commit/f8ea0937ec194347a4dcaacadc80d2608e137e1e

Comment by Githook User [ 23/Jul/19 ]

Author:

{'name': 'William Schultz', 'email': 'william.schultz@mongodb.com', 'username': 'will62794'}

Message: SERVER-42251 Timestamp multikey writes with the prepare timestamp during replication recovery

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.
Branch: master
https://github.com/mongodb/mongo/commit/7d687264de65258764dca70ce46754c4765912ce

Comment by William Schultz (Inactive) [ 22/Jul/19 ]

Code review url: https://mongodbcr.appspot.com/502180013/

Generated at Thu Feb 08 04:59:59 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.