[SERVER-37201] IndexConsistency::_indexKeyCount expects signed comparison but stores unsigned value Created: 19/Sep/18  Updated: 27/Oct/23  Resolved: 29/Jul/19

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

Type: Bug Priority: Major - P3
Reporter: James Wahlin Assignee: Geert Bosch
Resolution: Works as Designed Votes: 0
Labels: neweng, query-44-grooming
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: ALL
Sprint: Execution Team 2019-07-29
Participants:

 Description   

See here. _indexKeyCount stores map of hashed KeyString values to count. We increment this count for each key found while scanning a collection and decrement for each key we find in an associated index. We then expect the final count to be 0 if consistent, > 0 if the collection has a greater number of entries and < 0 if the index has a greater number of entries. Given this we should store the count in a signed integer rather than the current uint32_t.



 Comments   
Comment by Geert Bosch [ 29/Jul/19 ]

As part of my work on validation for performance improvements in SERVER-41537, committed by gregory.wlodarek as forward port of work on the 4.0 branch, I considered this issue, but decided that it would be an error to use a signed type because of the (theoretical) issue of overflow in case of truly excessive hash collisions.

So I added comments that make the use of the field more clear, see: https://github.com/mongodb/mongo/blob/63a71f3bea9ebd334343f8975d1855dd33affaf1/src/mongo/db/catalog/index_consistency.h#L153-L158.

Comment by David Storch [ 01/Jul/19 ]

Flagging this for triage by the execution team since they own index validation.

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