[SERVER-82099] WiredTigerRecordStore searchNear fails on backwards searches with oplog read timestamp Created: 11/Oct/23 Updated: 20/Nov/23 Resolved: 20/Nov/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 7.3.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Matthew Russotto | Assignee: | Daotang Yang |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Storage Execution
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | Execution Team 2023-11-13, Execution Team 2023-11-27 | ||||||||
| Participants: | |||||||||
| Description |
|
If you have a recovery unit with an oplog read timestamp which is between records (that is, there is no oplog entry with that read timestamp), then a backwards seekNear on a record ID corresponding to the oplog read timestamp or any later record ID will return boost::none instead of the proper previous record. I believe a similar problem could theoretically occur with visibility on forward searches, but it never does because WT search_near always returns the next record if it exists. |
| Comments |
| Comment by Githook User [ 20/Nov/23 ] |
|
Author: {'name': 'Daotang Yang', 'email': 'daotang.yang@mongodb.com', 'username': ''}Message: |
| Comment by Steven Vannelli [ 23/Oct/23 ] |
|
Thanks matthew.russotto@mongodb.com. We'll consider keep it as 7.3 targeted but will let you know if that changes. |
| Comment by Matthew Russotto [ 18/Oct/23 ] |
|
steven.vannelli@mongodb.com We may want to start using seekNear on the oplog as part of a (not yet out of the tiger team) performance improvement project, but I'm not actually blocked right now. |