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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org, 125atishprak(at)gmail(dot)com
Subject: Re: BUG #19857: Stats restore rejects empty arrays, losing range and array stats
Date: 2026-11-12 05:10:19
Message-ID: avVKOwRYbT6aD3wR@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Nov 11, 2026 at 11:55:08PM -0500, Corey Huinker wrote:
> But the problem still exists on 18, and that isn't a clean backport.
> Michael, do you want me to take that one?

The only problem that can be reached is if we dump or upgrade from a
v17 or v18 instance with the pattern of a range_empty_frac set with
range_length_histogram as NULL, where we could perhaps switch
range_length_histogram to '{}' under-the-hood on the dump side if a
range_empty_frac exists. I don't want the restore functions to live
eternally with a path authorizing for range_length_histogram=NULL if
there is a range_empty_frac, especially now that
range_length_histogram has to be an empty array since v19~.

And the end, I have no plans to bother based on the table definition
this requires. I could still care with something on the dump side,
but I doubt that's worth the effort anyway. What's been done on HEAD
and v19 is enough for these new empty-array cases. :)
--
Michael

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message shveta malik 2026-11-12 05:20:14 Re: BUG #19864: pg_get_publication_tables() gets cache lookup error after concurrent DROP PUBLICATION
Previous Message shihao zhong 2026-11-12 05:05:32 Re: BUG #19834: eager aggregation still evaluates volatile join clauses when the volatile function is inside a SubPl