Re: WAL_LOG CREATE DATABASE strategy broken for non-standard page layouts

On Mon, 31 Aug 2026 at 17:46, Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
>
> On Mon, Aug 31, 2026 at 1:37 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> >
> > Hmm. This warrants an open item for v19, at least to be discussed.
> > Adding Melanie in CC as the committer of add323da40a.
>
> This part

I think a message got cut off.

> As for whether we should log full page images of the VM and FSM in
> RelationCopyStorageUsingBuffer(), that kind of seems like the right
> direction to go, but that doesn't feel backpatchable to me. I
> understand this doesn't address Matthias' concern about certain AMs,
> but it seems like a good idea to have the VM and FSM up-to-date after
> promotion and FPIs of just those forks doesn't seem like an
> unacceptable increase in WAL volume. I don't know if doing this will
> have any side effects or causes bugs in other situations, though. I'd
> have to think more about it...

IIUC, CREATE DATABASE doesn't allow concurrent R/RW connections to the
template database, for neither WAL_LOG nor FILE_COPY. In this case
there shouldn't be any issues with copying VM pages that aren't
already present in the file-copy approach. The only difference here
would be that VM/FSM pages now get a more recent LSN on their pages,
and I think this should be fine because I can't think of a mechanism
that checks for (the consistency of) VM/FSM page LSNs.

Kind regards,

Matthias van de Meent
Databricks (https://www.databricks.com)