On Thu, 29 Oct 2026 at 07:11, shihao zhong <[email protected]> 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
0002-stored-setting-values-on-v4.diff
Description: Binary data
