On Tue, Feb 10, 2026 at 12:56:51PM +0900, Michael Paquier wrote:
> This is very slightly embarrassing. Compilation was warning here,
> just missed it. Thanks.
With 3b7a6fa15720 applied, taking care of the logical holes found
while reviewing this feature, I have looked again at this patch.
The patch has been stable in the last month, still I have spent a lot
of time torturing it in the last two days, mainly cross-checking the
input parameters, playing with a lot of injection, and found a few
holes while analyzing the code.
Here are my notes:
- The pg_dump query was broken for the three range fields added to
pg_stats_ext_exprs in v19. This has to be broken out in three parts:
one for inherited, one for the range fields, and the rest.
- One weird case I have been pondering about is a pre-v18 -> v19 case
with a range type, as the dump would not include the three range
fields in the data restore. At the end, rather than expecting a dump
and/or upgrade to test this scenario, I have added a SQL test that
emulates the same, at the end of stats_import.sql. That may feel
overkill, but this is dealing with a partial input, that we have to
authorize when restoring the numbers.
- The code forgot to check that if one of the three
"range_length_histogram", "range_empty_frac", or
"range_bounds_histogram" is set, the two others have to be set.
- The code forgot to check that a typtype of TYPTYPE_RANGE or
TYPTYPE_MULTIRANGE is required when passing in input the range_*
fields, like attributes. I was able to insert buggy data in the
catalogs with that.
- Some quote_literal in error messages, not wanted, with incorrect
quoting.
All that has been rather easy to fix at the end, so I have applied the
result. It should mean that ANALYZE is not required now after
pg_upgrade. The case of the three range_* fields feels annoying as we
lacked them until v19, meaning that we cannot restore them when
upgrading from a v14~v18 cluster. At least there is all the
infrastructure in place for them moving forward.
Anything else missing?
--
Michael
