[SERVER-62311] Validation can report false positive results when a hash collision happens Created: 29/Dec/21 Updated: 26/Feb/22 Resolved: 26/Feb/22 |
|
| 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: | Yuhong Zhang |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Operating System: | ALL | ||||
| Sprint: | Execution Team 2022-02-07, Execution Team 2022-02-21, Execution Team 2022-03-07 | ||||
| Participants: | |||||
| Linked BF Score: | 20 | ||||
| Description |
|
We reduced the chance of hash collision in For example, the collection has a record r1 and a matching index entry with hashes {h1, h2}. There is also an extra index entry without a matching record r2 with the hashes {h1, h3}. As a result, we will have both bucket h1 and h3 with non-zero values. The second phase in IndexConsistency::addDocKey() will think that r1 has a missing index entry since bucket h1 is non-zero. We may solve the problem by storing indexKeyCount as signed integers within IndexKeyBucket. |
| Comments |
| Comment by Yuhong Zhang [ 26/Feb/22 ] |
|
The problem described in the ticket should already be handled. The linked BF's log is expired so it's unclear what the actual problem was. Closing the ticket. |