[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: File repro.js    
Issue Links:
Backports
Depends
Related
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v3.6
Steps To Reproduce:

Run the attached repro.js:

python buildscripts/resmoke.py 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:

coll.find({a: 1, $or: [{b: 2}, {b: {$elemMatch: {$or: [{c: 4}, {c: 5}]}}}]});



 Comments   
Comment by Githook User [ 12/Feb/18 ]

Author:

{'email': 'david.storch@10gen.com', 'name': 'David Storch', 'username': 'dstorch'}

Message: SERVER-33005 Fix planner to avoid incorrect OR pushdown through $elemMatch.

The PlanEnumerator now tracks pushdown routes which descend
through an $elemMatch object. These routes are pruned when
subsequently descending through an OR.

(cherry picked from commit 17b4094c4d781ffd486b27869f46eea706e490af)
Branch: v3.6
https://github.com/mongodb/mongo/commit/228a8e7d410ae01dc2ee8b90a83ddf08aa219bc9

Comment by Githook User [ 09/Feb/18 ]

Author:

{'email': 'david.storch@10gen.com', 'name': 'David Storch', 'username': 'dstorch'}

Message: SERVER-33005 Fix planner to avoid incorrect OR pushdown through $elemMatch.

The PlanEnumerator now tracks pushdown routes which descend
through an $elemMatch object. These routes are pruned when
subsequently descending through an OR.
Branch: master
https://github.com/mongodb/mongo/commit/17b4094c4d781ffd486b27869f46eea706e490af

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:

2018-02-01T14:52:04.925-0500 D QUERY    [conn1] About to build solntree from tagged tree:
$and
    $or
        b $elemMatch (obj)  || Selected Index #0 pos 1 combine 1
            $or
                c $eq 4.0  || Selected Index #0 pos 1 combine 1
                c $eq 5.0  || Selected Index #0 pos 1 combine 1
        b $eq 2.0  || Selected Index #1 pos 0 combine 1
    a $eq 1.0  || Move to 0,0 || Selected Index #0 pos 0 combine 1 || Move to 0,1 || Selected Index #0 pos 0 combine 1

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.

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