[SERVER-40422] Add a test to test replaying prepare oplog entry behind stable timestamp as part of replaying commit oplog entry during rollback recovery and with a very small wiredTiger cache size. Created: 01/Apr/19  Updated: 29/Oct/23  Resolved: 16/Apr/19

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

Type: Task Priority: Major - P3
Reporter: Suganthi Mani Assignee: Suganthi Mani
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on WT-4714 Use the durable timestamp to determin... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2019-04-08, Repl 2019-04-22
Participants:

 Description   

Modify commit_transaction_rollback_recovery_data_already_applied.js to test replaying prepare oplog entry behind stable timestamp as part of replaying commit oplog entry during rollback recovery and with a wiredTiger cache size of 1GB.



 Comments   
Comment by Githook User [ 16/Apr/19 ]

Author:

{'email': 'suganthi.mani@mongodb.com', 'name': 'Suganthi Mani', 'username': 'smani87'}

Message: SERVER-40422 Modifies jstest to prepare and commit a transaction behind oldest timestamp during rollback recovery.
Branch: master
https://github.com/mongodb/mongo/commit/31fa6affccca75dac6e57be8df6f18a6fd02fd12

Comment by Vamsi Boyapati [ 09/Apr/19 ]

suganthi.mani, jocelyn.del-prado, I created a new ticket WT-4714 to fix the bug and unlinked the earlier WT-4612 from this ticket.

Comment by Vamsi Boyapati [ 09/Apr/19 ]

suganthi.mani, I think better to create a WT ticket. I will create the ticket and will link that to this SERVER ticket.

Comment by Suganthi Mani [ 08/Apr/19 ]

vamsi.krishna, I thought our suspect was "__wt_txn_visible_all".  But, anyways, I verified WT-4652 fix, still the test fails with the same reason.

Comment by Suganthi Mani [ 01/Apr/19 ]

Currently, commit_transaction_rollback_recovery_data_already_applied.js test this below scenario.

                                                      
|Start a txn T1 with 14MB of data|—————>|prepares a txn T1 at 2|—————>|commits a txn T1 at 3|———————>|stable ts at 5|—————>|commit oplog entry for txn T1 at 8|
                                                                                                        ==========> time                                                                    

Tested below following scenarios.

Case write size WT cache size  Rollback Recovery
(Recover to stable timestamp 5)
Test
1 14 MB 1 GB Doesn't abort the txn FAIL
2 14 MB 15GB Aborts the txn. PASS
3 14 bytes 1GB Aborts the txn. PASS

For case 1, the lesser cache size (which need cache eviction) makes __wt_txn_visible_all  to be called which returns true as committed ts <= stable ts (pinned ts). As a result, the page is marked clean and the txn updates aren't aborted.

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