[SERVER-15286] Assertion in date indexes when opposite-direction-sorted and double "or" filtered Created: 17/Sep/14 Updated: 11/Jul/16 Resolved: 18/Sep/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 2.6.3, 2.6.4 |
| Fix Version/s: | 2.6.5, 2.7.7 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Chad Kreimendahl | Assignee: | David Storch |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Operating System: | ALL | ||||||||
| Backport Completed: | |||||||||
| Steps To Reproduce: | Create a collection with at least 1 date field. Index the date field as ascending (1). Perform a query against the date with two filters and sort in the opposite direction of the index (-1) Recreating the index and rebuilding the database have no impact. |
||||||||
| Participants: | |||||||||
| Description |
|
When performing a find with two filters on the same indexed date field, a reverse sort on that same date field will cause an assertion:
Example:
|
| Comments |
| Comment by Githook User [ 18/Sep/14 ] |
|
Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}Message: (cherry picked from commit 55415503b722848d51fe45fc2de2d47cee4db952) |
| Comment by Githook User [ 18/Sep/14 ] |
|
Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}Message: |
| Comment by J Rassi [ 17/Sep/14 ] |
|
sallgeud, thanks for reporting this issue. I'm able to confirm it as a regression introduced in version 2.6.2 of the server. Please continue to watch this ticket for updates on when a fix will be available, and for updates on any workaround solutions that you may be able to employ. Assigning to hari.khalsa@10gen.com for triage. |
| Comment by Chad Kreimendahl [ 17/Sep/14 ] |
|
I forgot to add. Removing the index on the field resolves the issue. However, given the large set of data, this isn't practical long-term. |