| From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
|---|---|
| To: | shihao zhong <zhong950419(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-10-30 07:14:38 |
| Message-ID: | CAD21AoBzdxOunP4YONbMuMGuCPJU1NF-iX5wt=kT+Z3-es0vmA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Oct 28, 2026 at 7:11 PM 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.
>
I've researched this issue further with AI assistance, and I now
wonder if it's worth fixing these issues for v19, even in the
particular-case way I suggested before.
For instance, we introduced casts between bytea and int2/4/8 in v18
but didn't add any check to pg_upgrade, and I've not found any report
of an upgrade failing because of it. I confirmed that upgrading from
v17 to v18 fails in exactly the same way (--check passes, then the
restore fails) if the user had created such a cast. Similarly, we have
removed or restricted GUCs in past major versions without adding
checks. So while it would be better if pg_upgrade --check detected
such cases, whether we need to do something for v19 depends on how
likely users are to face this issue in practice, and I think it's
unlikely given these precedents. Therefore, I'm now inclined to think
these are not v19 bugs we must fix before release. For master, it
might be a good idea to improve pg_upgrade checks in a more general
way, so I think we can continue the discussion for v20 and later.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ian Lawrence Barwick | 2026-10-30 07:20:38 | Support "ALTER FOREIGN TABLE ... RENAME CONSTRAINT ..." |
| Previous Message | Hunaid Sohail | 2026-10-30 07:06:31 | Re: Proposal: SELECT * EXCLUDE (...) command |