[SERVER-14299] For sharded limit=N queries with sort, mongos can request >N results from shard Created: 18/Jun/14 Updated: 11/Jul/16 Resolved: 07/Jul/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 2.6.6, 2.7.4 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | J Rassi | Assignee: | David Storch |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Backport Completed: | |||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
If a user issues a limit=N query that includes a sort against a sharded collection and all of the first N results come back from one shard, mongos will request an extra batch of results from that shard. This bug has a particularly harmful interaction with the "top-K sort" logic introduced in version 2.6.0 of the server. If mongos requests >N results from a shard for a query that has a limit of N and uses an unindexed sort, then the shard will perform a full "unlimited" sort (and return "getMore runner error: Overflow sort stage buffered data usage..." to the user if the size of the data to be sorted exceeds the 32MB sort stage limit; see script attached to this ticket for an example that exhibits this failure mode). Reproduce with the following:
The query on line 21 requests 9 documents from both shards, and then an unnecessary additional batch from shard 0:
Whereas the query on line 22 requests 9 documents from both shards and does not follow up with any getmore requests:
|
| Comments |
| Comment by Githook User [ 19/Nov/14 ] |
|
Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}Message: (cherry picked from commit 8b8a118fc965231293ad56c53a837ffacb17132f) Conflicts: |
| Comment by Githook User [ 07/Jul/14 ] |
|
Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}Message: |