Re: [PG19] pg_upgrade --check passes, then the upgrade fails

On Thu, 29 Oct 2026 at 07:11, shihao zhong <zhong950419(at)gmail(dot)com> wrote:
>
> Hi Masahiko,
>
> I think that a better fix for v19 would be to check these particular
> > cases (i.e., standard_conforming_strings = off, escape_string_warning,
> > and user-defined uuid<->bytea casts) only if the old cluster is 18 or
> > older, like check_for_not_null_inheritance() and
> > check_for_gist_inet_ops() do, and we can seek a more generic approach
> > for v20+.
>
> Thanks for your testing. Okay, let's take care of 19 first. I can create a different
> thread for 20+.
>
> I added two checks next to check_for_gist_inet_ops(). Both run only
> when the old cluster is 18 or older. The first lists roles, databases
> and functions that set standard_conforming_strings to off or set
> escape_string_warning. The second lists user casts between uuid and
> bytea.
>
> I attached a version for 19 too.
>
>

Hi

I reviewed v4 and found some more cases that v4 does not cover. Its
when setting is still present, but value is not supported:

alter role app set default_toast_compression = lz4;
--> ERROR: invalid value for parameter "default_toast_compression": "lz4"
--> HINT: Available values: pglz.

alter role app set wal_compression = lz4; -- also zstd
--> ERROR: invalid value for parameter "wal_compression": "lz4"

v4 --check passes while pg_upgrade itself does not.
So I think we need separate value validation check, not this +
"'^standard_conforming_strings=(0|f|fa|fal|fals|false|n|no|of|off)$' "
\
One option is to actually try run set_config on new cluster for each
GUC-value pair. Attached does that. Its PoC, and its partally
AI-generated, but in my by-hand A/B test it does catch incompatable
setting, while bening cluster upgrade succeeds

--
Best regards,
Kirill Reshke