[PG19] pg_upgrade --check passes, then the upgrade fails
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t254362psql -h localhost -U postgresBuilt from patchset v1 (message #1), October 24, 2026 at 04:16 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t254362_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t254362_1 && git checkout t254362_1Patchset v1 (message #1) is on t254362_1
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