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

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

In response to

Responses

Browse pgsql-hackers by date

  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