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

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