[SERVER-25630] Add validation of splitVector output Created: 16/Aug/16  Updated: 06/Dec/22  Resolved: 15/Dec/16

Status: Closed
Project: Core Server
Component/s: Querying, Sharding
Affects Version/s: 3.2.8
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Kevin Pulo Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-25602 splitChunk command with out of bound ... Closed
related to SERVER-27082 validate() can't catch certain corrup... Closed
Assigned Teams:
Sharding
Operating System: ALL
Sprint: TIG 2016-09-19, TIG 2016-10-10, TIG 2016-10-31
Participants:

 Description   

It is possible for the splitVector command to return split points that are outside the min/max range that it was told to search, when there is data corruption. This can cause downstream problems for splitChunk (see SERVER-25602).

To keep potential problems in splitVector contained, it could have one or both of the following sanity checks:

  • Have a postcondition that all the split points being returned lie between min (inclusive) and max (exclusive).
  • Somewhat equivalently, have a loop invariant that the currKey variable always lies between min and max.

(However, it may be more appropriate to fail the splitVector command, rather than to completely abort the mongod with an fassert/invariant failure.)



 Comments   
Comment by Andy Schwerin [ 15/Dec/16 ]

Consumers of the output of splitVector should validate the output if it's important to them. Eventually, we may remove splitVector entirely, and replace it with a regular query. Expecting the query subsystem to detect arbitrary data corruption may be impossible in general.

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