[SERVER-39036] Stop pinning stable timestamp behind prepared transactions Created: 16/Jan/19  Updated: 29/Oct/23  Resolved: 02/Apr/19

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

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

Issue Links:
Depends
depends on WT-4607 Allow prepared transaction to commit ... Closed
depends on SERVER-39035 Specify durable_timestamp when commit... Closed
depends on SERVER-40008 Storage Interface changes to specify ... Closed
is depended on by SERVER-37886 Remove config server as coordinator c... Closed
is depended on by SERVER-39038 Remove the restriction that the ‘olde... Closed
is depended on by SERVER-39039 Persist commit decision with writeCon... Closed
is depended on by SERVER-39040 Coordinator should send prepareTransa... Closed
is depended on by SERVER-39510 Test that transaction coordinator goi... Closed
is depended on by SERVER-39991 Add transactions workloads to failove... Closed
is depended on by SERVER-40268 Add a test that should test reconstru... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2019-02-25, Repl 2019-03-11, Repl 2019-03-25, Repl 2019-04-08
Participants:
Linked BF Score: 10

 Description   

We will no longer pin the stable timestamp behind the oldest prepare timestamp, or behind the oldest prepare timestamp of a transaction whose corresponding commit/abort oplog entries have not been majority committed. That is, we will revert SERVER-35811.



 Comments   
Comment by Kelsey Schubert [ 30/Jul/19 ]

committed under https://github.com/mongodb/mongo/commit/e433a5aee915568cf73b05e89597903855ed1952

Comment by Pavithra Vetriselvan [ 26/Feb/19 ]

siyuan.zhou, I think this is fixed by suganthi.mani's work on SERVER-39035, which went in today. 

Comment by Siyuan Zhou [ 19/Feb/19 ]

In Pavi's recent work for rollback, the timestamp a rollback recovered to is passed into applyCommitTransaction() to check whether a commit oplog entry has been applied or not. With Oplog Durability project, that's no longer correct, since all oplog entries after the rollback recovery timestamp have to be applied, no matter whether their commit time is greater than the rollback recovery timestamp or not. I can't find a ticket related to that work, so I'm making a note here. CC tess.avitabile.

Comment by Samyukta Lanka [ 07/Feb/19 ]

This ticket should also address these TODOs.

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