Re: Add expressions to pg_restore_extended_stats()
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Corey Huinker <corey.huinker@gmail.com>
Cc: Chao Li <li.evan.chao@gmail.com>, Tender Wang <tndrwang@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Tomas Vondra <tomas@vondra.me>
Date: 2026-03-03T05:36:50Z
Lists: pgsql-hackers
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
Commits
-
Refactor tests for catalog diff comparisons in stats_import.sql
- ccd7abaa456f 19 (unreleased) landed
-
Fix typo in stats_import.sql
- 9e8193a26229 19 (unreleased) landed
-
Add support for "exprs" in pg_restore_extended_stats()
- ba97bf9cb7b4 19 (unreleased) landed
-
Add information about range type stats to pg_stats_ext_exprs
- 307447e6dbc0 19 (unreleased) landed
-
Fix comment in extended_stats_funcs.c
- 9476ef206c64 19 (unreleased) landed