[SERVER-71489] tassert tripped when using a cached ixscan plan involving a partialFilterExpression with $or and non-simple collation Created: 18/Nov/22 Updated: 13/Jan/23 Resolved: 13/Jan/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Nicholas Zolnierz | Assignee: | Nicholas Zolnierz |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | query-director-triage | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
| Assigned Teams: |
Query Optimization
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Steps To Reproduce: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||||||||||
| Linked BF Score: | 16 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
A tassert can be tripped when using a plan cache entry that performs an index scan over a partial index with a filter containing $or and a non-simple collation. The bounds validity check fails when checking whether intervals are ordered correctly. Theoretically the query that causes the tassert should not be eligible for the plan cache entry, since it contains a collation-sensitive string value in the predicate. |
| Comments |
| Comment by Nicholas Zolnierz [ 04/Jan/23 ] |
|
I've confirmed that the plan cache key's are identical for the collation-sensitive query and the collation-insensitive query, even though the filter on the partial index has a competing collation. This is because the discriminator for the partial index is 0 (ineligible) for both the {$in: [1, 2]} as well as the {$in: ["Small Analyst", "parsing Zambia Metal"]} predicates, even though the first should be eligible. It's worth noting that although the plan cache key indicates that the index is not compatible with the query, the planner uses a different set of logic which is actually correct for the collation-insensitive case. I believe that |
| Comment by David Storch [ 16/Dec/22 ] |
|
Flagging for re-scheduling as maybe this slipped through the cracks. I would think that we should generally put in the effort to fix tassert() failures. |
| Comment by Nicholas Zolnierz [ 18/Nov/22 ] |
|
Marking as related-to |