On Sat, Oct 31, 2026 at 5:21 PM shihao zhong <[email protected]> wrote: > > > Hi Masahiko, > > Fair point on the casts. The bytea and int casts in 18 are the same > case, so I'm fine dropping the cast check. > > I'd still like to fix the standard_conforming_strings part in 19. > Commit 45762084545 says "pg_upgrade will work transparently even if > the source installation has standard_conforming_strings = off". That > holds for the server default. It does not hold when a role, database > or function sets it. So this looks like a gap in that commit, not an > old class of problem. > > Stored settings that break an upgrade do get reported. 69d5ca484b6 was > back-patched in 2021 after two separate reports of ALTER ROLE ... SET > role failing an upgrade. > > If you agree, I'll send a v5 with only that check. If you still think > it's not worth it for 19, I'm fine with that and will move on to the > general check for 20.
I understand that the current behavior looks inconsistent with what the commit message of 45762084545 says. That said, looking at the past cases, we have several similar ones. The most recent one is default_with_oids: it became a dummy GUC in v12 and setting it to true has been effectively unusable since then, so it has exactly the same problem. So I think we can consider the standard_conforming_strings case not a new problem either. I don't see a reason why standard_conforming_strings is more likely to be attached to a database, role, or function than those GUCs, and I could not find any report of pg_upgrade failing for this reason. As for 69d5ca484b6, I'm not sure that we can use it as a precedent. What we chose there was to make the restore succeed by relaxing the GUC check hooks for PGC_S_TEST, not to make pg_upgrade --check detect the problem. Also, even if we fix standard_conforming_strings in v19, IIUC holes remain. For example, force_parallel_mode was renamed in v16 without an alias, so an upgrade from v15 or earlier with it attached to a role fails the same way, and v19's pg_upgrade is also used for upgrades from such older versions. So if we fix this, I think we need to cover not just standard_conforming_strings but all GUCs whose compatibility was broken across major versions. Given that, while I agree that it would be good behavior for pg_upgrade --check to detect these cases, I'm not sure we can call the current behavior a v19 bug. Others may think differently, but I think it's better to discuss and address this on master. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
