[SERVER-19388] assertion in sort.cpp Created: 14/Jul/15 Updated: 05/Feb/16 Resolved: 15/Jul/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | 3.1.6 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Eric Milkie | Assignee: | David Storch |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Sprint: | Quint Iteration 6 | ||||||||
| Participants: | |||||||||
| Description |
|
We have a build that runs nightly that runs the MMS integration tests against the head of MongoDB master. This morning we had the following failure.
|
| Comments |
| Comment by Githook User [ 15/Jul/15 ] | ||||||||||||||||||||||||||||||
|
Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}Message: | ||||||||||||||||||||||||||||||
| Comment by J Rassi [ 14/Jul/15 ] | ||||||||||||||||||||||||||||||
|
Filed Per discussion with Dave, the tentative plan for this ticket is to revert the changes to the three-argument version of CanonicalQuery::canonicalize(). This wouldn't fix the issue of the wrong predicate being passed to the sort key generation process inside subplanned clauses, but I believe this is benign, as it does not affect the tags generated for the subplanned clause. We will need some other fix for viewing the plan cache entries for subplanned clauses, though (which was the original motivation for changing the three-argument version of canonicalize()); Dave will file a ticket for this. | ||||||||||||||||||||||||||||||
| Comment by J Rassi [ 14/Jul/15 ] | ||||||||||||||||||||||||||||||
|
The regression was introduced by the fact that the three-argument CanonicalQuery::canonicalize() was changed in 15c72c85 to initialize the underlying LiteParsedQuery with a filter serialized from the parsed MatchExpression, instead of using the original query object for the filter. The issue is that the sort stage key generator re-parses the LiteParsedQuery's filter in order to generate bounds, and query predicates created from the parsing+serialization process aren't necessarily valid for re-parsing. The issue can be reproduced as follows:
When the subplanner receives the above query, it invokes the three-argument canonicalize() function in order to create a new CanonicalQuery object for the first OR child. The re-underlying LiteParsedQuery's re-serialized filter for this child is {$not: {a: {$eq: 1}}}, and the plan enumeration process for this child generates two SORT <= FETCH <= IXSCAN plans. When the plan selection process for this child is invoked, the sort stage attempts to re-parse the LiteParsedQuery's filter as part of sort key generation; this fails with the error "unknown top level operator: $not". Reverting changes to canonical_query.cpp from the above commit fixes the immediate issue of tripping the assertion in sort.cpp, however I believe it's actually incorrect for the full $or expression to be used as the predicate for sort key generation here. I'll file tickets separately for the issue(s) I've uncovered in the sort key generation process as part of investigating this bug report, and link them here. | ||||||||||||||||||||||||||||||
| Comment by Cory Mintz [ 14/Jul/15 ] | ||||||||||||||||||||||||||||||
|
MongoDB log:
| ||||||||||||||||||||||||||||||
| Comment by Eric Milkie [ 14/Jul/15 ] | ||||||||||||||||||||||||||||||
|
Cory says the query that caused the failure has a mix of $or and $and, so I'm suspecting the recent change to $or query planning may be related. |