Mixed-schema measurement predicate safety
Parent: Bucket-level predicate rewriting for measurement operators · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for Mixed-schema measurement predicate safety. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Structure and components
- Time-series measurement pushdown must preserve every bucket that could contain a match. MongoDB's query README describes control.min/control.max bucket filters before unpacking; SERVER-59505 demonstrates why naïvely applying these bounds to mixed arrays/scalars or objects/non-objects can wrongly discard matching measurements. (high confidence) [source]
How it works
- SERVER-59505 reproduces x:[0,2], x:[3,1], and x:10 in one bucket whose control.min.x is 10: an unsafe pushed-down x<5 test excludes the bucket even though array elements match. It also shows that control.max.x.y need not be the maximum of x.y when x mixes objects and non-objects. (low confidence) [source]
- The old-collection explanation is not exhaustive: SERVER-107361 records that keeping buckets open for large measurements could skip schema checks even when timeseriesBucketsMayHaveMixedSchemaData was false. Percona's release notes repeat this upstream defect and its upgrade-plus-collMod remediation. (medium confidence) [source]
Problems, failure modes and limitations
- Methodological inference: an empty result caused by unsafe bucket pruning cannot be repaired merely by choosing a faster access path. Investigate correctness separately before attributing observed behavior to replanning; these bug records do not establish a replanReason signature. (medium confidence) [source]
- In the master MixedSchemaBucketsState header read on 2026-10-30, mustConsiderMixedSchemaBucketsInReads returns true for every state except NoMixedSchemaBuckets, explicitly including Invalid to fail safe. canStoreMixedSchemaBucketsSafely returns true only for DurableMayHaveMixedSchemaBuckets. (low confidence) (verified as of 2026-10-30) [source]
- A firsthand September 2022 report describes a measurement-field index build failing on MongoDB 6.0.1 with a mixed-schema bucket error while metadata/time-field indexes succeeded. This is a historical user observation, not evidence that measurement indexes are generally unsupported in 6.0+. (low confidence) [source]
Facts and statements
- MongoDB's time-series query implementation describes measurement equality filtering with control.max >= value and control.min <= value before unpacking. This is bucket pruning; mixed-type correctness requires additional care beyond the simplified bounds example. (medium confidence) [source]
- SERVER-59505 lists fixes in 5.0.4, 5.1.0-rc3, and 5.2.0. Its reproducer describes a historical defect and must not be presented as proof that all current mixed-schema queries return incorrect results. (low confidence) (verified as of 2024-12-12) [source]
- SERVER-91194 documents that cloning collections created in 5.0–5.1 could lose timeseriesBucketsMayHaveMixedSchemaData, making queries miss matches. TOOLS-3777 explains why a true catalog flag can remain unsafe if its durable WiredTiger configuration representation is absent. (medium confidence) [source]
- For collections affected by SERVER-91194, the documented remediation combines upgrading to a fixed version with setting timeseriesBucketsMayHaveMixedSchemaData:true using collMod. An upgrade alone does not prove historical collection metadata is repaired. (high confidence) [source]
- SERVER-107361 lists fixed versions 7.0.26 and 8.0.13, alongside 8.2.0-rc3 and 8.3.0-rc0. Percona documents inclusion of the fix in its 7.0.26-14 release; this is downstream confirmation of an upstream fix, not an independent discovery. (medium confidence) (verified as of 2025-11-25) [source]
- MongoDB records SERVER-59505 as fixed in 5.0.4, 5.1.0-rc3 and 5.2.0. These historical fix versions do not establish that every later mixed-schema defect is fixed. (low confidence) (verified as of 2024-12-12) [source]
- SERVER-91194 concerns collections created in 5.0–5.1 and subsequently cloned after upgrade: initial sync, chunk migration, movePrimary, resharding and dump/restore could default timeseriesBucketsMayHaveMixedSchemaData to false. Missing flag information can make reads omit matching documents that remain stored. (high confidence) [source]
- validate can detect mixed-schema buckets inconsistent with the catalog flag. SERVER-91194 warns that validation can be impactful and recommends its linked hidden-secondary procedure to reduce production impact. (high confidence) [source]
- SERVER-107361 shows that large-measurement bucket rollover could return kNone before checking schema incompatibility, permitting mixed-schema data despite a false catalog flag. This scopes any blanket claim that post-5.2 bucket creation always prevents mixed schemas. (high confidence) [source]
- SERVER-107361 lists fixes in MongoDB 7.0.26, 8.0.13, 8.2.0-rc3 and 8.3.0-rc0. Percona's 7.0.26-14 and 8.0.16-5 notes include the fix and repeat the requirement to flag affected collections after upgrading; these release notes describe incorporated upstream fixes, not independent discovery. (high confidence) (verified as of 2026-09-29) [source]
- For investigation of replanning loops, treat mixed-schema predicate safety as a separate correctness prerequisite: the cited defects concern unsafe bucket pruning or lost catalog state. They do not establish that a replanReason message identifies or repairs mixed-schema buckets; this is a diagnostic inference from the defect mechanisms. (medium confidence) [source]
Children
- No children recorded.