Re: BUG #19814: pg_restore_attribute_stats: MCV accepted without eq operator; ANALYZE range slot rejected

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: 303677365(at)qq(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19814: pg_restore_attribute_stats: MCV accepted without eq operator; ANALYZE range slot rejected
Date: 2026-10-31 00:26:18
Message-ID: auU1qnlHQ-k4IcNy@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Oct 29, 2026 at 07:00:28AM +0000, PG Bug reporting form wrote:
> Two defects in pg_restore_attribute_stats(), in opposite directions: one
> check is missing (invalid statistics are accepted), one check is too strict
> (statistics that ANALYZE itself produces are rejected). Both reproduce on
> the official postgres:latest docker image (18.6).

Like the other reports of this kind, does this lead to a crash of the
backend and/or an assertion failure? If the backend is able to handle
its own, even if it's just an elog(ERROR), I see nothing that needs to
be done here.

If you can find out a case able to take down the server or point at a
code path that needs adjustments in terms of stats loading, please
post it.

Stats injections is a feature in itself, not a bug. Breaking a
backend stack based on the data read from the catalogs would be a bug.
Catalog inconsistency between ANALYZE and the restore functions will
not be treated as a bug.

Without more data to prove a point, I see nothing to do here.
--
Michael

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2026-10-31 00:28:34 Re: BUG #19815: 004_sni.pl fails deterministically with OpenSSL 1.1.1 (tests 75 and 86)
Previous Message Michael Paquier 2026-10-31 00:19:57 Re: BUG #19821: pg_restore_attribute_stats() accepts an unsorted scalar histogram_bounds, producing badly wrong row