Re: [PATCH] pg_restore_extended_stats() can store an MCV list that cannot be read back

On Tue, Jun 16, 2026 at 11:15:46AM +0800, Ewan Young wrote:
> The statistics object is then unusable until cleared. With more than
> 65535 items, an assertion-enabled build crashes instead (the Assert in
> mcv_get_match_bitmap()).
>
> The cause is a write/read asymmetry: import_mcv()
> (extended_stats_funcs.c) hands the input item count to
> statext_mcv_import() unbounded, while statext_mcv_deserialize()
> (mcv.c) rejects nitems > STATS_MCVLIST_MAX_ITEMS. This is the same
> family as 6d6348f0329 (CVE-2026-6575) and 0b8fa5fd37b, both of which
> note import_mcv() was not affected by their issue -- the item-count
> bound is a separate, still-open gap.

Hmm. While I was re-reading statext_mcv_[de]serialize(), my first
thought was if we'd have a risk of out-of-bound read when the data is
loaded back, but I don't see a pattern here. So while the problem is
the same as 6d6348f0329, the consequences are not alarming. The case
where we have more than 65k items is problematic because we can have a
wraparound calculation in statext_mcv_serialize() (close to the
"compute index within the deduplicated array"), meaning that we would
read buggy data, not point at an incorrect memory area.

> The attached patch adds that bound to import_mcv(), rejecting an
> oversized list with a WARNING before anything is stored. A regression
> test is added to stats_import.sql; "make check" passes.

Sounds good to me. Thanks for the report.

Before someone asks, the extstats restore code has inherited this
pattern from the attribute restore code, where functions like
var_eq_const() don't care about the limitation in the number of MCV
items, even with a attstattarget MAX_STATISTICS_TARGET (10k) that caps
the number of MCVs on ANALYZE. So one could inject more items than
10k, but contrary to the extstats case they can be loaded back without
an error.
--
Michael