Re: Reject ill-formed range bounds histograms in pg_restore_attribute_stats()

Thanks for looking!

On Wed, Jul 8, 2026 at 10:17 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> 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.
Done in v2. I moved the check to stat_utils.c as stats_check_bounds_histogram()
and now call it from both pg_restore_attribute_stats() and
pg_restore_extended_stats(). In the extended path I reject an ill-formed
histogram the same way the sibling stakinds there already do — WARNING plus
goto pg_statistic_error.

>
> 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.
Agreed — v2 targets master only, no back-branch patches.

> --
> Michael

--
Regards,
Ewan Young