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

On Thu, Aug 6, 2026 at 2:39 PM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>
> On 05/08/2026 08:15, John Naylor wrote:
> > I think my phrasing was ambiguous: When I said "the system must know
> > what file paths to stick into the WAL stream", I didn't mean creating
> > path strings, I meant the enumeration done by capture_all_relfiles()
> > etc. Normally, a WAL record enters the stream because a logged write
> > happens. In the patch, the input to WAL comes from a directory walk of
> > already-written files. If this walk misses anything, then the standby
> > diverges from the primary.
>
> It'd be pretty hard to screw up walking all files in a directory ;-). I
> don't think missing some files is a serious concern.

Okay, the enumeration aspect isn't as bad as I made it out to be, and
is probably light on maintenance. The whole architecture still feels
hackish, though: transam/ and rmgrdesc/ have a significant amount of
new logic in service of a frontend tool that only runs once in a
cluster's lifetime, and redo can (and by design, must) have different
physical effects depending on new settings.

--
John Naylor
Amazon Web Services