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

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

In response to

Browse pgsql-hackers by date

  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