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 <[email protected]> wrote: > On Fri, Jul 31, 2026 at 8:14 PM Bohyun Lee <[email protected]> > 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 >
