There was an error while loading. Please reload this page.
Correct five claims the upgrade rig measured as false Each change below was found by tests/run-cluster-upgrade.sh, which follows this document literally against a real three-node mesh and reports every claim that does not hold. * Fence the peers too (step 6). Step 3 disabled only N's own subscriptions, so until step 9 every peer's apply worker kept retrying N's address. Whatever came up there collected those connections: pg_upgrade's own short-lived server, whose slot check then failed with `replication slot "..." is active for PID`, and in production the upgraded instance itself, before step 8 had restored anything. Dropping the peer subscriptions while N is still running costs nothing -- requirement 5 already drove the debt to zero and 7(b) already recorded the definitions -- and lets sub_drop() remove the slot on N while it can still reach it. * sub_skip_schema is not Spock 6 only. Both the column and the skip_schema argument arrived in spock--5.0.1--5.0.2.sql, so only 5.0.0 and 5.0.1 lack them. The advice to probe rather than assume was already right; the version claim behind it was not. * pg_upgrade does not carry postgresql.auto.conf, so requirement 2 is violated again the moment N restarts and nothing later notices. Say so in step 7. * Compare restored origins as pg_lsn, not as text. PostgreSQL 18 pads the low word, so 0/1B93898 reads back as 0/01B93898 and a text comparison calls every correctly restored origin wrong. * Qualify "the outbound position cannot be preserved". From a PG17-or-later old cluster pg_upgrade does migrate logical slots -- measured, and the migrated slot carries data. Step 6 drops the slot deliberately so the procedure stays the same on every old major rather than branching on one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Initial Home page