[SERVER-80654] Handle older index entry formats where keystring does not have recordID appended correctly for reverse lookup Created: 31/Aug/23  Updated: 19/Jan/24

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

Type: Task Priority: Major - P3
Reporter: Huayu Ouyang Assignee: Backlog - Replication Team
Resolution: Unresolved Votes: 0
Labels: pm-855-milestone-2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-80960 Handle old keystring formats in uniqu... In Code Review
Assigned Teams:
Replication
Sprint: Repl 2023-11-27, Repl 2023-12-25, Repl 2024-01-08
Participants:

 Description   

Based on https://github.com/10gen/mongo/blob/c5c3086dcae61481f80664f1de1dcd965aee2147/src/mongo/db/catalog/README.md#use-in-wiredtiger-indexes:

During reverse lookup we should check if the secondary is unique or not, because for unique indexes the keystring might be stored without the recordID appended.

Right now in reverse lookup we get the recordID from the keystring with decodeRecordId here, so that wouldn't work if the keystring doesn't have the recordID appended.

It's possible we could just get the RecordId from the KeyStringEntry struct though in all cases: https://github.com/10gen/mongo/blob/bbf84d93a5bb9a9aaa3d7a52acd14673772d4997/src/mongo/db/storage/index_entry_comparison.h#L126

Additionally, when we call getKeys we should check whether we should be passing in the recordId - if the keystring didn't have the recordID appended then I don't think we should pass in the recordId here either.


Generated at Thu Feb 08 06:44:10 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.