[SERVER-32441] 3.6 mongod crash on find with index and nested $and/$or Created: 21/Dec/17 Updated: 30/Oct/23 Resolved: 05/Jan/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Index Maintenance |
| Affects Version/s: | 3.6.0 |
| Fix Version/s: | 3.6.3, 3.7.1 |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | Michael Jansen | Assignee: | David Storch |
| Resolution: | Fixed | Votes: | 1 |
| 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: | 1. mongoimport -h 127.0.0.1 --port 27017 -d test -c tc --jsonArray --file ./tc.json )' |
||||||||||||||||||||||||
| Sprint: | Query 2018-01-01, Query 2018-01-15 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||
| Description |
|
When executing a find with $and $or which uses an index command mongod crashes. with Invariant failure childDestinations->second.size() == 1 src/mongo/db/query/index_tag.cpp 180
|
| Comments |
| Comment by Douglas Reith [ 07/Feb/18 ] | ||
|
I think Atlas users can't use
perhaps everyone on 3.6.2 on Atlas should have this set by default for now? | ||
| Comment by Githook User [ 05/Jan/18 ] | ||
|
Author: {'name': 'David Storch', 'username': 'dstorch', 'email': 'david.storch@10gen.com'}Message: This fix removes the planner's ability to generate (cherry picked from commit 87c1731e3e077ca9e8b750ebe4b3fef534f1cbe6) | ||
| Comment by Githook User [ 05/Jan/18 ] | ||
|
Author: {'name': 'David Storch', 'username': 'dstorch', 'email': 'david.storch@10gen.com'}Message: This fix removes the planner's ability to generate | ||
| Comment by Michael Jansen [ 21/Dec/17 ] | ||
|
works! much appreciated. thank you! | ||
| Comment by David Storch [ 21/Dec/17 ] | ||
|
The problem has to do with a bad interaction between the $or access planning improvements made in
This should prevent the issue until we can provide a fix in the 3.6 branch. | ||
| Comment by Michael Jansen [ 21/Dec/17 ] | ||
|
thank you for looking into it. when you have the fix. I will use it immediately. thank you! | ||
| Comment by David Storch [ 21/Dec/17 ] | ||
|
Hi michaeljansen, thanks for reporting this issue. I can reproduce using the steps provided, and am looking into the root cause. I also confirmed that this does not reproduce against 3.4, so it is a regression introduced in 3.6. It looks related to the work done under |