On Wed, Oct 28, 2026 at 7:11 PM 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. >
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
