[SERVER-39038] Remove the restriction that the ‘oldest_active_txn_timestamp’ is greater than the initial data timestamp before exiting ‘STARTUP2’ Created: 16/Jan/19  Updated: 27/Oct/23  Resolved: 11/Apr/19

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

Type: Task Priority: Major - P3
Reporter: Tess Avitabile (Inactive) Assignee: Pavithra Vetriselvan
Resolution: Gone away Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-37973 Do not leave initial sync until ‘stab... Closed
depends on SERVER-39036 Stop pinning stable timestamp behind ... Closed
Sprint: Repl 2019-04-08, Repl 2019-04-22
Participants:

 Description   

Remove the restriction that all transactions that were in the prepared state at the initial data timestamp be committed before exiting ‘STARTUP2’. There might be no additional work for this after SERVER-39036, since the way this restriction was enforced was by pinning the stable timestamp behind the oldest prepare timestamp (SERVER-35811) and enforcing that we do not leave 'STARTUP2' until the stable timestamp is greater than the initial data timestamp (SERVER-37973).

We will leave SERVER-37973 in place because it is independently useful, since it ensures that a node will not require a full resync if it crashes or goes into rollback after exiting ‘STARTUP2’.

This work should not be started until testing for initial sync for Prepare Support for Transactions is complete, so that we can check that initial sync tests still pass after this change.



 Comments   
Comment by Tess Avitabile (Inactive) [ 11/Apr/19 ]

Thank you for investigating, pavithra.vetriselvan. I agree that there is no work to do.

Comment by Pavithra Vetriselvan [ 11/Apr/19 ]

I don't think there is any work to do here because it looks like we do not actually enforce that the "oldest_active_txn_timestamp" is greater than the initial data timestamp. We set the initial data timestamp to the last applied here at the end of initial sync. The earliest that the last applied could be is the "oldest_active_txn_timestamp" if one exists, so the initial data timestamp could never be before it.

As mentioned in the ticket, we enforced this by pinning the stable timestamp behind the oldest prepare timestamp ("oldest_active_txn_timestamp"). The only way the stable timestamp could advance past this and, subsequently, the initial data timestamp, is if the corresponding prepared transaction gets committed/aborted.

Comment by Tess Avitabile (Inactive) [ 21/Mar/19 ]

Determine if there is any work to do here. Prepare may not yet have made any change to require that the oldest active transaction timestamp is greater than the initial data timestamp when exiting initial sync.

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