On Mon, 31 Aug 2026 at 17:46, Melanie Plageman <[email protected]> wrote: > > On Mon, Aug 31, 2026 at 1:37 AM Michael Paquier <[email protected]> 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)
