| 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
| 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 |