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

On Thu, 29 Oct 2026 at 09:57, Kirill Reshke <reshkekirill(at)gmail(dot)com> wrote:
>
> 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

v4+mydiff misses v11 -> v20 default_with_oids upgrade

pg_upgrade_utility.log:
ALTER ROLE "oidsuser" SET "default_with_oids" TO 'on';
psql: .../pg_upgrade_dump_globals.sql:36: ERROR:
tables declared WITH OIDS are not supported

new-cluster server log:
2026-10-29 05:37:20.339 UTC [4002982] ERROR:
tables declared WITH OIDS are not supported
2026-10-29 05:37:20.339 UTC [4002982] STATEMENT:
ALTER ROLE "oidsuser" SET "default_with_oids" TO 'on';

But I think we can ignore this problem due to lack of actual complains
across all this years after WITH OIDS removal

--
Best regards,
Kirill Reshke