Re: Why clearing the VM doesn't require registering vm buffer in wal record

On Wed, Sep 16, 2026 at 12:10 PM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
>
> There is an interaction between CREATE DATABASE STRATEGY WAL_LOG and
> this fix that causes data corruption (identified while investigating
> [1]). The scenario is you have a heap page set PD_ALL_VISIBLE and a
> corresponding VM page set all-visible, you do a CREATE DATABASE
> STRATEGY WAL_LOG using that database as a template. The primary has
> the heap page set PDV (PD_ALL_VISIBLE) set and VM page AV set but the
> standby does NOT have the page set all-visible in the VM (it does have
> the heap page set PDV). After failover you have a primary with heap
> page PDV set and VM page not set. You modify a tuple on the page.
> Because the VM was already clear, we do not register the VM block in
> the WAL record. The standby replays this and clears the heap page
> PD_ALL_VISIBLE but leaves the VM set. This is data corruption leading
> to wrong results from index scans and worse if that standby is later
> promoted back to primary.
>
> We didn't have this problem before ed62d26caca because it cleared the
> VM during replay as long as PD_ALL_VISIBLE needed clearing. I mention
> in the thread [2] that I think we have to fix
> RelationCopyStorageUsingBuffer() to avoid producing this scenario
> because tuple locking already caused data corruption before
> ed62d26caca. However, for update/delete, etc, I'm wondering if we
> should harden this a bit and go back to registering a vm clear
> operation whenever PD_ALL_VISIBLE was set on the heap page. If this is
> a no-op on the primary for the VM, we register it with
> REBGUF_NO_CHANGE. Vacuum works very hard to never end up with
> PD_ALL_VISIBLE cleared and the VM set. Perhaps we should do everything
> we can to avoid this happening with page modifications as well.

We can't WAL-log all pages that might possibly be out-of-sync on the
standby even if we didn't need to modify them on the primary. And the
above approach would kind of set that precedent. As an alternative,
the attached patch makes sure the VM is clear on the standby even when
the VM block was not registered and emits a warning. It isn't
resilient to torn pages since we won't have emitted an FPI on the
primary, however, since it is making a best attempt to repair
corruption, I think that's fine.

This would only need to be backpatched to 19.

- Melanie