Re: BUG #19857: Stats restore rejects empty arrays, losing range and array stats

On Wed, Nov 11, 2026 at 8:32 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:

> On Thu, Nov 12, 2026 at 10:26:00AM +0900, Michael Paquier wrote:
> > I cannot really get excited to allow this combination in the restore
> > functions, though, as it means being more lenient on
> > range_length_histogram forever, and the v19~ decision of using an
> > empty array is much better to me in the long term. An extra argument
> > is that this case is super narrow anyway, unlikely to be hit in
> > practice? As far as I can see, you need a [multi]range column with
> > less than *2* non-empty values..
>
> Or we could do something on the dump side, forcing an empty array out
> if seeing a NULL range_length_histogram.. Still not sure if that's
> worth bothering, just saying.
> --
> Michael
>

I had also considered fixing it dump-side as well, which seems cleaner but
also means that the bug would persist in pre-existing dump files, though as
you mention it may not be worth bothering because this is a corner case
that only occurs if the histogram was less than 2 elements long, thus the
query plan wouldn't be that far off. Also, such a pre-existing dump file
would itself be restored to a cold-start database, and therefore unlikely
to be getting flooded with queries before vacuumdb has had time to run in
the way that a pg_upgrade-ed database would.

Commit looks good on master and REL_19_STABLE.