Re: BUG #19842: pg_restore_extended_stats() rejects a faithful pg_dump of ANALYZE-produced range expression statisti

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
Cc: 303677365(at)qq(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19842: pg_restore_extended_stats() rejects a faithful pg_dump of ANALYZE-produced range expression statisti
Date: 2026-11-13 06:02:28
Message-ID: avan9H8xvnx9F2iG@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Nov 12, 2026 at 04:07:54PM -0500, Corey Huinker wrote:
> 0001 -
> Decoupling range_bounds_histogram. No changes since last patchset where it
> was number 0002.

Ah, I see what you are getting at here. Without this part a portion
of 0003 is actually moot, and the reason where there is no point to
check for range_bounds_histogram in parallel of range_length_histogram
and range_empty_frac is that they use a different stats slot.

Tweaked a few things here, and applied down to v19.

> 0002 -
>
> Fix to pg_dump to handle NULL values in range_length_histogram and
> most_common_elems when their corresponding stanumbers field is not null.
>
> I was able to test this against 18, however I [1] was not able to
> synthesize data such that an extended statistics object on 18 that had
> expression stats with a NULL most_common_elems and NOT NULL
> most_common_elem_freqs. I asked Claude to try to do it as well, and it too
> was not able to.

I have not been able to process this one today, unfortunately. I had
to choose what to do, and picked up the most important matters based
on their priority.

> 0003 -
> This has the same goals as the original 0003, but using the methods laid
> out in 2656f664616d.

While the code changes were fine, to allow for empty arrays like in
2656f664616d, the tests were bundled at the bottom of
stats_import.sql. We have already sections of the tests that check
similar patterns, so I have just moved the whole in sections that are
more adapted for this goal. Applied also this one, after some edits.

Should we also include a test where empty arrays are allowed but we
have a multi-dimension array in input? I have refrained from doing so
to not complicate more the patch and there were enough tests to check
for the basics in terms of v19. Your patch did not do that, either.

0001 and 0003 were by far the most urgent items to handle for v19 (and
actually the less risky ones). Without 0002 for the moment, it still
means that we could miss some stats at dump/restore due to the
NULL/empty change introduced in v19 when upgrading from v17/18, but at
least we are clear for any future moves, or when doing a dump from
v19.
--
Michael

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message JaeHyuck Sa 2026-11-13 06:10:16 Re: BUG #19602: Vuln46: citext split_part silently returns NULL for a zero field position instead of raising core sp
Previous Message Nisha Moond 2026-11-13 04:42:53 Re: BUG #19884: pg_publication_tables omits a detach-pending partition in root mode