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

On Fri, Oct 2, 2026 at 12:27 AM Bohyun Lee <bohyun(dot)lee(at)databricks(dot)com> wrote:

> 2. Handoff atomicity and shutdown ordering
>
> Feedback: the old primary might continue processing transactions after the
> handoff. The handoff command should shut down the primary at the handoff record.
> The handoff could also be represented by the shutdown checkpoint itself.

Marking the shutdown checkpoint is precisely the approach I've taken
in my own work, so I've attached two small patches to show this. They
were extracted from a larger series that's not quite ready to share,
so some details may need to change. There are a couple forward-looking
bits that are out of context, but it's mostly independent of the rest.

I didn't share earlier because I didn't think it was quite compatible
with your proposal, but since you mentioned it, I'm now curious how
close it is to being compatible.

It's worth calling out the fact that the old binary must be aware of
the "handoff" (my series calls it a "version boundary" or "upgrade
boundary", but it seems to be the same concept). In my view, whatever
the old binary needs is as much as we can commit for PG20, and
anything in the target version should probably not be committed until
PG21 at the earliest. They have to be developed together, so timing is
a bit tricky, but using the shutdown checkpoint seems to me the least
invasive way to be forward-looking. Your first patch (I haven't looked
at the second) didn't distinguish the needs of the old and new
binaries cleanly since it was a single patch. (BTW, 0002
conventionally means the second patch in a series, applied on top of
0001 in order. You can make git add patch numbers and version numbers
with `git format-patch master -v 2`)

--
John Naylor
Amazon Web Services