[SERVER-24320] Planner can attempt to use invalid index when using plan cache due to plan cache key / MatchExpression sorting inconsistency Created: 31/May/16 Updated: 20/Nov/16 Resolved: 26/Jul/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Geo, Querying |
| Affects Version/s: | 3.2.6, 3.3.6 |
| Fix Version/s: | 3.2.10, 3.3.11 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | David Storch | Assignee: | Tess Avitabile (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | code-and-test | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||||||||
| Backport Completed: | |||||||||||||||||||||||||||||||||||||||||||
| Steps To Reproduce: |
|
||||||||||||||||||||||||||||||||||||||||||
| Sprint: | Query 16 (06/24/16) | ||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||
| Description |
|
The 2dsphere geo query in the repro steps trips the following verify(): https://github.com/mongodb/mongo/blob/r3.3.6/src/mongo/db/query/index_bounds_builder.cpp#L596 This affects the 3.2 branch as well as 3.3.x development versions. 3.0.x versions are not affected. |
| Comments |
| Comment by Githook User [ 18/Aug/16 ] |
|
Author: {u'username': u'tessavitabile', u'name': u'Tess Avitabile', u'email': u'tess.avitabile@mongodb.com'}Message: |
| Comment by Githook User [ 26/Jul/16 ] |
|
Author: {u'username': u'tessavitabile', u'name': u'Tess Avitabile', u'email': u'tess.avitabile@mongodb.com'}Message: |
| Comment by David Storch [ 09/Jun/16 ] |
|
Another update: I believe this was first broken in the 3.1.3 development release as part of the plan cache work done in support of partial indexes. Specifically, this problem was introduced by https://github.com/mongodb/mongo/commit/88f6f4733bca7c615dd6fedcfc93a24cfa68372a under https://github.com/mongodb/mongo/blob/r3.3.8/src/mongo/db/query/canonical_query.cpp#L64 In addition to fixing the problem reproduced here, we should audit to ensure that there are no other discrepancies between plan cache key generation and MatchExpression sorting. |
| Comment by David Storch [ 09/Jun/16 ] |
|
I've done some initial investigation and have some results to report. Read on for some of the technical details. The $within-$polygon predicate used in the problem query is only compatible to be indexed by a "2d" index; it is intended for use with a flat geometry rather than a spherical one. This is documented here:
and is enforced in the query planner's index selection process here: https://github.com/mongodb/mongo/blob/r3.3.8/src/mongo/db/query/planner_ixselect.cpp#L307-L312 A $within $polygon query always has a flat coordinate reference system, which will cause hasS2Region() to return false, thus indicating that the predicate is not compatible with the "2dsphere" index. In the reproducing script above, the first run of the problem query indexes only the $within $centerSphere predicate and the $gte—the $within $polygon predicate is correctly left unindexed and instead is affixed as a filter to be performed after the index scan. An entry is then inserted to the plan cache with some information that should allow us to reconstitute the original plan. The problem occurs when, on execution of the second query, we attempt to construct the plan using the plan cache entry. The plan cache code is mistakenly attempting to index the $within $polygon predicate rather than the $within $centerSphere predicate. In turn, the downstream invariant check that the geo predicate being answering with a 2dsphere index has a spherical coordinate reference system is tripped! Some more investigation will be required to determine a strategy for fixing the issue, as well as identifying the scope of the bug and possibly the original breaking commit. Please continue to watch for updates. |