Reposting this: my first reply (Aug 12) never threaded correctly and didn't show up here. Sorry for the duplicate to those who already saw it.
This thread solves the same problem as mine (pg_upgrade_replica [1]). Different design, worth comparing. > The transfer mode setting seems strange and not well motivated to me. I have a similar choice: --tablespace-mapping. It's a command-line flag, not a WAL record, so it never has to mean the same thing twice. That's also why pg_upgrade_replica stays in src/bin/: it reuses pg_upgrade's own manifest, a real backup_manifest, and pg_basebackup --incremental's own WAL-summary code. No new WAL format, no core redo change. Its only new core footprint is one small manifest file. > For rollback, can't the operator just pause the rollback target at the > handoff checkpoint while still on the old binary and promote if > necessary? Yes, in my design: --old-replica stays read-only and bootable on the old binary. Unless --link is used, then the new standby's first write corrupts it too, the same tradeoff pg_upgrade's own --link already makes. One thing your design fixes that mine doesn't: a primary that crashes before the next backup or resync. WAL-logging makes recovery just normal replay across the upgrade. My tool only runs after the upgrade, against an already-running primary. Hüseyin Demir's point about tablespace layout and cascading replicas applies to me too. --tablespace-mapping doesn't assume the standard pg_tblspc/ layout, but cascading isn't special-cased: each hop still needs its own run. Two questions for Bohyun: - WAL size: full block images for every changed catalog and SLRU block. How big does this get on a real cluster, not just the TAP tests? - RELINK's ENOENT skip: is it reachable only for files that are correctly absent (an unlogged relation's main fork), or could a real missing file hit it too and leave a silent gap? Two valid answers to the same problem. Wanted the comparison on record. [1] https://www.postgresql.org/message-id/flat/CA%2BnrD2fqdeEJkGJrDt%2B-a7Uqr4OucXZHvSVxLCb9J0EkN%2BhLhw%40mail.gmail.com Marco Nenciarini EnterpriseDB On Tue, Aug 11, 2026 04:30 PM, John Naylor <[email protected]> wrote: > On Thu, Aug 6, 2026 at 2:43 PM Heikki Linnakangas <[email protected]> wrote: > > > > On 06/08/2026 01:17, John Naylor wrote: > > > On Wed, Aug 5, 2026 at 9:36 PM Bohyun Lee > > > <[email protected]> wrote: > > >> The GUCs are introduced because we cannot assume the standby's > > >> storage layout exactly matches the primary's, neither where the > > >> retained pre-upgrade directory sits, nor how its files are > > >> physically placed. It also depends on how the cluster intends to > > >> use the standby. For instance, if the operator wants to keep the > > >> standby as a rollback target, it may be worthwhile to use a > > >> different transfer mode via the newly introduced > > >> pg_upgrade_standby_transfer_mode GUC, which I believe is useful. > > >> Nevertheless, the reconstructed cluster will be logically > > >> identical, even if the physical representation diverges. > > > > > > Given the above design concepts, I still think WAL is fundamentally > > > the wrong mechanism for this. > > > > Can you elaborate? Do you think the changes that pg_upgrade makes should > > be written somewhere else than WAL, or is this just about the transfer > > mode setting, or something else? How would you do it? > > The transfer mode setting seems strange and not well motivated to me. > For rollback, can't the operator just pause the rollback target at the > handoff checkpoint while still on the old binary and promote if > necessary? Am I missing something? > > -- > John Naylor > Amazon Web Services > > > > >
