-
Type: Improvement
-
Resolution: Won't Do
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Query Execution
In recent tickets SERVER-59676 and SERVER-58689, we ran into an issue where a sub-operation pipeline issued via MongoProcessInterface behaved incorrectly in cases where the requested collection was shard-local, i.e. a collection which can exist on each shard independently. We worked around this issue using the NamespaceString::isNamespaceAlwaysUnsharded method, which is almost a synonym for the proposed isPerShardNamespace method. However, isNamespaceAlwaysUnsharded includes the system.views namespace, which is not shard-local but always exists, unsharded, on the primary shard for the given database. There may be other or future cases where the two concepts do not perfectly overlap.
Given this, we should add a specific NamespaceString::isPerShardNamespace method. This would be identical to the existing isNamespaceAlwaysUnsharded with the exception of the isSystemDotViews check. The isNamespaceAlwaysUnsharded method could then be re-expressed in terms of isPerShardNamespace, i.e. (isSystemDotViews() || isNamespaceAlwaysUnsharded()).
We should also consider using this new helper in attachCursorToPipeline, to have the pipeline automatically decline to send a remote request if the given namespace is per-shard.
- is related to
-
SERVER-59676 DocumentSourceFindAndModifyImageLookup can hit invariant when used in a shard
- Closed
-
SERVER-59839 ShardServerProcessInterface::getCollectionOptions returns format differently from non-sharded versions
- Closed