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

On Mon, Aug 3, 2026 at 4:01 PM Bohyun Lee <bohyun(dot)lee(at)databricks(dot)com> wrote:

> 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 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. Also, the result of RELINK depends on a
GUC, so IIUC two standbys can receive the same WAL and end up with
different results. That's not good.

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

On the odd chance you are using an LLM to write emails, I suggest
refraining. While on the subject of list etiquette, please see the
following on top- versus bottom-posting:

https://en.wikipedia.org/wiki/Posting_style#Bottom-posting

> 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.

I need to make sure my orchestration story is on solid ground before
sharing anything publicly. One thing that hadn't crossed my mind yet
is the possibility of getting PITR to work through an upgrade
boundary. That's what I found most compelling about the presentation
of your patch, and I'll have to keep that in mind as I proceed.

--
John Naylor
Amazon Web Services