| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Ewan Young <kdbase(dot)hack(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
| Subject: | Re: Reject ill-formed range bounds histograms in pg_restore_attribute_stats() |
| Date: | 2026-07-08 02:17:06 |
| Message-ID: | ak2zIgGdJfyna2-o@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jul 07, 2026 at 04:13:30PM +0800, Ewan Young wrote:
> The attached patch validates the bounds histogram at import time and
> rejects an ill-formed one with a WARNING, matching the treatment of the
> other inconsistent inputs. Because the histogram element type is a range
> for both range- and multirange-typed columns, the single check covers
> both.
I have been looking at that, and while the consequences of buggy
inputs are minor when loaded back, I don't really mind putting more
defenses to inform about that at the front of the restore functions.
Now, your patch is entirely blind about extended statistics; these can
also load histogram bounds. The function you are introducing to
filter the inputs provided could be reused in this secondary case,
just by moving to stat_utils.c.
I am not really convinced that any of this stuff would be worth a
backpatch, even if it's non-invasive. We don't have guards for
buggy infinite values, even if using empty or unordered bounds feels
kind of a stupid thing to do if one is a table owner.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Smith | 2026-07-08 02:25:52 | Re: Support EXCEPT for ALL SEQUENCES publications |
| Previous Message | Tom Lane | 2026-07-08 02:07:37 | Re: [PATCH] Fix null pointer dereference in PG19 |