| From: | shihao zhong <zhong950419(at)gmail(dot)com> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, ilmari(at)ilmari(dot)org |
| Subject: | Re: [PG19] pg_upgrade --check passes, then the upgrade fails |
| Date: | 2026-11-01 00:21:35 |
| Message-ID: | CAGRkXqRH3_KB6OjKOuXYWwChsOu9AviqXo7o66Ng5on+sbv=0Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
Thanks,
Shihao
| From | Date | Subject | |
|---|---|---|---|
| Next Message | shihao zhong | 2026-11-01 00:45:20 | Re: [PG19] Bogus errors for polymorphic plpython functions |
| Previous Message | shihao zhong | 2026-11-01 00:16:31 | Re: Proposal: Conflict log history table for Logical Replication |