[SERVER-41270] Partial transactions before the beginApplyingTimestamp in sync_tail cannot be read. Created: 22/May/19  Updated: 29/Oct/23  Resolved: 23/May/19

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 4.1.12

Type: Bug Priority: Major - P3
Reporter: Matthew Russotto Assignee: Matthew Russotto
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Gantt Dependency
has to be done before SERVER-39810 Make the new txn format the default Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Repl 2019-06-03
Participants:
Linked BF Score: 0

 Description   

For initial sync, we have the beginFetchingTimestamp which tells us when to start retrieving the oplog to make sure we have all partial transactions, and the beginApplyingTimestamp which tells us when to start applying those oplog entries (anything before that is assumed to have been applied).  If an oplog application batch has partial entries for a transaction before and including beginApplyingTimestamp, and a commit or prepare entry after, these entries may not have been written to the oplog and will not be found, causing an fassert.

 

 

There are two possible ways to fix this:

1) Always place a batch boundary just after beginApplyingTimestamp (the oplog entry with that timestamp is not applied  or

 

2) "Apply" partial transactions even when they are <= the beginApplyingTimestamp.

 

The first should be more straightforward, as the second requires special handling of commit, abort, and prepare also (it must clear the partial transaction list for that transaction for the current batch)



 Comments   
Comment by Githook User [ 23/May/19 ]

Author:

{'email': 'matthew.russotto@10gen.com', 'name': 'Matthew Russotto', 'username': 'mtrussotto'}

Message: SERVER-41270 Split batch after beginApplyingTimestamp in initial syncer.
Branch: master
https://github.com/mongodb/mongo/commit/94a51a07190a945e41166c0987a04227ab5f18f2

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