-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 6.0.17, 5.0.29, 8.0.0-rc18, 7.0.14
-
Component/s: Distributed Query Planning, Sharding
-
None
-
Query Optimization
-
Fully Compatible
-
ALL
-
v8.0, v7.0, v6.0, v5.0
-
-
QO 2024-09-16, QO 2024-09-30, QO 2024-10-14
-
0
In the case where we have a collection with non-simple default collation, and the collection is sharded on a field where the backing index has a simple collation (what's important here is that its just a different collation from the default collection collation), we cannot do shard targeting for an equality query with a non-simple collation so we broadcast the query to all shards. However, we also do not do shard filtering in this case. So if a chunk migration happens right before the query and the source shard hasn't yet cleaned up orphans, we will return duplicate results. I've attached a more thorough repro in the "steps to reproduce" section.
This happens on master, 8.0, 7.0, 6.0, and 5.0 (i.e. the repro I attached succeeds on all these versions).
- is caused by
-
SERVER-39191 Performance regression for counts post-sharding
- Closed
- related to
-
SERVER-94611 Update SHARDING_FILTER logic to support non-simple collation sharding
- Open
-
SERVER-92488 Expand IDHACK eligibility to include {_id: {$eq: <val>}}
- Closed