Re: [Patch]The Case For WAL-Logging pg_upgrade

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 <johncnaylorls(at)gmail(dot)com> wrote:

> On Thu, Aug 6, 2026 at 2:43 PM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> >
> > On 06/08/2026 01:17, John Naylor wrote:
> > > On Wed, Aug 5, 2026 at 9:36 PM Bohyun Lee
> > > <bohyun(dot)lee(at)databricks(dot)com> 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
>
>
>
>
>