[SERVER-33005] Contained $or access planning is incorrect for $elemMatch object, results in invariant failure Created: 30/Jan/18 Updated: 29/Oct/23 Resolved: 09/Feb/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 3.6.0, 3.7.1 |
| Fix Version/s: | 3.6.3, 3.7.2 |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | Charlie Swanson | Assignee: | David Storch |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Operating System: | ALL | ||||||||||||
| Backport Requested: |
v3.6
|
||||||||||||
| Steps To Reproduce: | Run the attached repro.js:
|
||||||||||||
| Sprint: | Query 2018-02-12 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
The server crashes when a query is eligible for an OR pushdown through an $elemMatch object with an $or descendent. This issue only affects query shapes that involve an $elemMatch-$or construction, such as the following:
|
| Comments |
| Comment by Githook User [ 12/Feb/18 ] | |||||||||
|
Author: {'email': 'david.storch@10gen.com', 'name': 'David Storch', 'username': 'dstorch'}Message: The PlanEnumerator now tracks pushdown routes which descend (cherry picked from commit 17b4094c4d781ffd486b27869f46eea706e490af) | |||||||||
| Comment by Githook User [ 09/Feb/18 ] | |||||||||
|
Author: {'email': 'david.storch@10gen.com', 'name': 'David Storch', 'username': 'dstorch'}Message: The PlanEnumerator now tracks pushdown routes which descend | |||||||||
| Comment by David Storch [ 01/Feb/18 ] | |||||||||
|
We're not handling OR pushdowns through $elemMatch object correctly in the PlanEnumerator. From logLevel 5 in the "query" component:
In particular, note the OR pushdowns associated with the "a $eq 1.0" predicate. These pushdowns are not correct. Pushing down through the $elemMatch object causes the path to be "b.a" rather than just "a", but index 0 does not include "b.a" in its key pattern. | |||||||||
| Comment by Charlie Swanson [ 31/Jan/18 ] | |||||||||
|
This appears to have turned up another bug that needs investigation, or was harder to fix than we thought. Assigning to Dave to continue investigation. |