| 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
| 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 |