On Wed, Sep 16, 2026 at 5:59 PM Robert Haas <[email protected]> wrote: > > 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?
That was before I realized that it allows us to trivially cause a serious data corruption bug with tuple locking. We should definitely backpatch the part that passes false for VM and FSM. > 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. Andres suggested off-list having CreateDatabaseUsingWalLog() thread information from the catalog about whether the page is a normal heap page down into RelationCopyStorageUsingBuffer(). I looked into it and we could, when scanning source database pg_class (ScanSourceDatabasePgClassTuple()), check something like: RELKIND_HAS_TABLE_AM(classForm->relkind) && classForm->relam == HEAP_TABLE_AM_OID and allowing the "hole punching" if so. And, it's even easier to do this in RelationCopyStorage() without any extra catalog info because the callers know what type of relation it is. So, we could fix RelationCopyStorageUsingBuffer() and make it consistent with RelationCopyStorage() at the same time (master only). - Melanie
