On Mon, Aug 31, 2026 at 11:47 AM Melanie Plageman <[email protected]> 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
