[SERVER-68740] Non-default-seeded hashed indexes not working correctly since 2.6 Created: 11/Aug/22  Updated: 17/Jul/23  Resolved: 17/Jul/23

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

Type: Bug Priority: Major - P3
Reporter: Yuhong Zhang Assignee: Backlog - Storage Execution Team
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-68309 Investigate for unsafe narrowing conv... Closed
is related to SERVER-68741 Remove code handling the non-default ... Closed
Assigned Teams:
Storage Execution
Operating System: ALL
Participants:

 Description   

We introduced hashed indexes in 2.4, where we could take an option seed to compute the hash and it worked accordingly. Since 2.6, we computed the hashes for the keystrings using the non-default seed as expected, but when running the query we incorrectly used the default hash key. (The code hasn’t been really changed and here’s the link to them on master: insertquery) Starting from 3.4, we disallowed users to pass the seed option. This option would never be touched throughout upgrades. After 5.0, it will be automatically skipped when calling listIndexes. The validate command can detect this disallowed field on disk, and users can use collMod to remove it from the catalog. Also, it doesn't seem to have any documentation of the seed field, not even on 2.4 where we introduced it.

Since we haven't really got any complaints from our users, I'm not sure if we would want to implement any fix at all to make the non-default seeded indexes to work correctly. On the other hand, we may want to consider removing the code handling the non-default seed on master.


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