-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 5.0.28, 7.0.13, 6.0.17
-
Component/s: None
-
Query Integration
-
Fully Compatible
-
ALL
-
v8.0, v7.3, v7.0, v6.0, v5.0
-
Execution Team 2024-02-19, Execution Team 2024-03-04
-
200
In SERVER-66469 we fixed timeseries filtering of extended-range data by disabling some predicate pushdown optimizations for collections that have the "requires extended range support" in-memory flag set.
However, this flag is per-process, so any time one node plans a query to be executed on another, we need to know the value of the flag where the query will execute.
SERVER-66469 attempts to fix this by checking the flag during view resolution, which in a sharded cluster happens on the primary shard. So if the collection contains extended-range data, but none of it is on the primary shard, mongos will push down more predicates than it should, and the query can miss events outside the 32-bit range.
We need some mechanism for mongos to know whether extended-range events exist anywhere in the collection.
- depends on
-
SERVER-66469 Filtering timeseries with date-field does not include results from before 1970
- Closed
- is depended on by
-
SERVER-94485 Refactor createPredicatesOnBucketLevelField() to use visitors and walkers
- Backlog
-
SERVER-93149 Re-enable reshardingForTimeseriesFeatureFlagEnabled
- In Code Review
- related to
-
SERVER-92896 Incorrect queries on timeseries with extended range on non dbPrimary (root cause not fixed - disabled resharding for timeseries so the bug can't occurr on moved unsharded collections)
- Closed
-
SERVER-95075 _id predicates no longer generated for time series update or delete
- Closed
-
SERVER-73024 Re-enable time-series sharded passthrough suites
- Closed
-
SERVER-74211 [6.0] Temporarily prevent timeseries_filter_extended_range.js from running in multiversion suites
- Closed