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

From: shihao zhong <zhong950419(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, ilmari(at)ilmari(dot)org
Subject: [PG19] pg_upgrade --check passes, then the upgrade fails
Date: 2026-10-24 04:05:25
Message-ID: CAGRkXqT+5+mQhoKZFTiM4yOZtVV=NW506vDwFtVeG+VmL_W5wQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

i hackers,

From 18 to 19, pg_upgrade --check passes for both of these, then the
upgrade fails:

alter role app set standard_conforming_strings = off;
ERROR: non-standard string literals are not supported

create cast (uuid as bytea) with function uuid_send(uuid);
ERROR: cast from type uuid to type bytea already exists

With the patches, --check reports these before the upgrade starts.
0001 lists roles, databases and functions that store a setting the new
cluster rejects.

0002 lists user casts that are now built in. Both ask the new cluster,
so the next removed setting or new cast is caught too.

Both work like check_loadable_libraries(), which collects names from the
old cluster and tries them on the new one.

0003 is a optional test

I think this is a 19 open item.

Thanks,
Shihao

Attachment Content-Type Size
v3-0002-pg_upgrade-Check-user-defined-casts-against-the-n.patch application/octet-stream 6.4 KB
v3-0001-pg_upgrade-Check-stored-settings-against-the-new-.patch application/octet-stream 10.8 KB
v3-0003-pg_upgrade-Test-a-stored-setting-unknown-to-the-n.patch application/octet-stream 1.9 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Zsolt Parragi 2026-10-24 04:36:50 Re: [PATCH] Refactor pgbench to make future improvements easier
Previous Message shihao zhong 2026-10-24 04:00:00 Re: [PG19] Three bugs with a CHECK constraint that only the child enforces