[SERVER-73641] Timeseries filtering can miss extended-range events when sharded Created: 06/Feb/23  Updated: 07/Feb/24

Status: Open
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: David Percy Assignee: Backlog - Storage Execution Team
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-66469 Filtering timeseries with date-field ... Closed
Related
related to SERVER-73024 Re-enable time-series sharded passthr... Closed
related to SERVER-74211 [6.0] Temporarily prevent timeseries_... Closed
Assigned Teams:
Storage Execution
Operating System: ALL
Participants:
Linked BF Score: 29

 Description   

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.


Generated at Thu Feb 08 06:25:14 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.