[SERVER-37967] Backup cursor truncate after test can choose to recover before the checkpoint timestamp Created: 06/Nov/18  Updated: 29/Oct/23  Resolved: 12/Nov/18

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

Type: Bug Priority: Major - P3
Reporter: Daniel Gottlieb (Inactive) Assignee: Daniel Gottlieb (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Storage NYC 2018-11-19
Participants:
Linked BF Score: 56

 Description   

The backup_cursor_truncate_after test will always try setting the truncate after point to the top of oplog. However, that timestamp is "inclusive" meaning replication recovery will try to remove that document. If that oplog entry is also the checkpoint timestamp, that document is majority committed and cannot be removed. The test should omit that scenario when it occurs.



 Comments   
Comment by Githook User [ 17/Nov/18 ]

Author:

{'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com', 'username': 'dgottlieb'}

Message: SERVER-37967: Only include backup cursor test scenarios that are in front of the checkpoint.
Branch: tongo
https://github.com/10gen/mongo-enterprise-modules/commit/56db57b2d0e46a71d45a0d56418ae985e2db00b3

Comment by Githook User [ 12/Nov/18 ]

Author:

{'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com', 'username': 'dgottlieb'}

Message: SERVER-37967: Only include backup cursor test scenarios that are in front of the checkpoint.
Branch: master
https://github.com/10gen/mongo-enterprise-modules/commit/56db57b2d0e46a71d45a0d56418ae985e2db00b3

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