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

Hi John,

Thank you for sharing your thoughts and providing this context.

If you're referring to relinking user relations with filesystem primitives
during the upgrade (the XLOG_UPGRADE_RELINK manifest), that redo path
reproduces exactly what pg_upgrade already does for each transfer
mode—link(), copyfile()/FICLONE, copy_file_range(), copy_file(), and
rename(). Upstream already performs bulk filesystem transformations today:
--link hardlinks every user relation, --clone reflinks them, and --swap
renames whole database directories. Therefore, the transformation itself
isn't new; what changes is where it happens.

The RELINK WAL record also doesn't contain paths: entries carry
(tablespace_oid, database_oid, relfilenumber, forknum, segno), and redo
derives the path in the same form as xl_dbase_create_file_copy_rec. Only
DIRTREE and RAWFILE carry paths.

I take the layering concern to be the more substantive one, and I don't
think "the primitives are upstream's" answers it.

Could you say more about the other options you have in mind and share your
prototype if it's shareable? I'd be glad to work in that direction if that
would provide a better foundation.

Best regards,

Bohyun

On Sat, Aug 1, 2026 at 2:31 AM John Naylor <johncnaylorls(at)gmail(dot)com> wrote:

> On Fri, Jul 31, 2026 at 8:14 PM Bohyun Lee <bohyun(dot)lee(at)databricks(dot)com>
> wrote:
> > The patch closes both gaps by atomically WAL-logging the after-images
> generated by pg_upgrade upon successful completion. The upgrade becomes
> part of the WAL stream and can be propagated to standbys through standard
> streaming replication, eliminating the need for offline rsync-based
> resynchronization.
>
> This is an interesting proposal. I think a new RMGR that ships a
> filesystem transformation through the WAL stream might be a difficult
> sell. It's different in that the system must know what file paths to
> stick into the WAL stream to get the desired result. It also changes a
> lot of the backend to support new capabilities in a frontend tool. If
> we're changing this much in the tree, we have other options to arrange
> for normal WAL to physically propagate the primary's changes, since
> that's a desireable feature. Coincidentally, I've been prototyping
> ideas lately as well.
>
> --
> John Naylor
> Amazon Web Services
>