-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 4.4.4
-
Component/s: Querying
-
None
-
Fully Compatible
-
ALL
-
v4.9, v4.4, v4.2, v4.0
-
-
Query Execution 2021-03-08, Query Execution 2021-03-22, Query Execution 2021-04-05, Query Execution 2021-04-19, Query Execution 2021-05-03, Query Execution 2021-05-17
-
145
Manifestation of the bug: The impossibility to execute the $merge pipeline stage
Consider the case in which the $merge pipeline stage is executed in a shard that:
- Has the CollectionShardingState correctly updated with the latest shard version of the target collection.
- Doesn't currently hold any entry in the cache for the target collection.
(This is possible because the sharding catalog cache is a LRU cache in which not frequently used entries can be evicted.)
The shard executes DocumentSourceMerge::createFromBson() that triggers a call to MongoProcessInterface::ensureFieldsUniqueOrResolveDocumentKey(). This function in the end throws a StaleConfigInfo because the target collection is not present in the cache. The error is correctly handled by the shard that will execute the onShardVersionMismatch() procedure.
Since the CollectionShardingState already contains the latest shard version for the target collection no action will be taken and no refresh of the catalog cache will be triggered.
In other words if the CollectionShardingState is up to date, the StaleConfigInfo won't guarantee that the catalog cache will be refreshed.
- is related to
-
SERVER-56763 Validate collection epoch when not holding a DB lock for $merge
- Closed
- related to
-
SERVER-56815 Complete TODO listed in SERVER-54507
- Closed