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

On Mon, Aug 31, 2026 at 11:47 AM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
> 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...

I feel like treating the VM and FSM as non-standard pages is the right
thing to do, because in fact they are not standard pages. Unless you
know something I don't, I think we need to fix
RelationCopyStorageUsingBuffer to treat them that way. What's your
reason for not wanting to back-patch that change?

AFAICS, the tougher question is what to do about the main fork. I
originally resisted the idea of treating all pages as non-standard
pages here because, well, most of the time they will be standard, and
treating them as non-standard adds considerable expense. However, a
bit of exploration with Claude poked a few holes in this idea. It
notes that:

1. RelationCopyStorage treats all pages as non-standard, so having
RelationCopyStorageUsingBuffer do otherwise is inconsistent.

2. ginDeletePostingPage has a comment saying that GIN uses
non-standard pages prior to 9.4.

3. The value of STRATEGY WAL_LOG is that it's faster for small
databases, so the additional WAL volume may not be a huge deal anyway.

So I'm starting to think Matthias had the right idea back in 2024. It
still seems like a lamentable change to me, but to quote Tom quoting
an unnamed wise man: "I can make this code arbitrarily fast, if it
doesn't have to give the right answer." As far as that goes, point #2
is the strongest argument: there aren't likely many people who have a
GIN index that hasn't been rewritten since pre-9.4 and who have that
index inside of a database that they use as a template, but any such
people who do exist will be justifiably annoyed if CREATE DATABASE
with any set of options produces a corrupt copy.

--
Robert Haas