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

Hi,

On 2026-03-05 18:11:43 -0500, Robert Haas wrote:
> On Thu, Mar 5, 2026 at 3:38 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > If checksums are enabled, we are already emitting FPIs for the VM when
> > *setting* bits in the VM (c.f. log_heap_visible()). I don't see why the story
> > for clearing it should be different. And because there are so few VM pages
> > compared to heap pages, I wouldn't expect there to be a meaningful amount of
> > VM FPIs outside of very contrived workloads.
>
> Yeah, that's how it seems to me, too, at least as of this moment.
>
> Is there any indication in the code or comments that this was an
> intentional omission because somebody thought we could get away
> without doing it?

I couldn't find any evidence of that, which of course doesn't mean it doesn't
exist.

> Or is just a straight-up goof?

It kinda looks like a victim of multiple subsequent changes that each arguably
should have done something different:

commit 2c03216d831
Author: Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi>
Date: 2014-11-20 17:56:26 +0200

Revamp the WAL record format.

Which should have included a reference to the VM page in the WAL record for
insert/update/delete.

and

commit 96ef3b8ff1c
Author: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Date: 2013-03-22 13:54:07 +0000

Allow I/O reliability checks using 16-bit checksums

Which should have triggered an FPI when clearing the VM, as afaict there
otherwise is no guarantee the checksum will be correct after a crash.

and, although I am not sure it's true:

commit 503c7305a1e
Author: Robert Haas <rhaas(at)postgresql(dot)org>
Date: 2011-06-21 23:04:40 -0400

Make the visibility map crash-safe.

Which perhaps also should have emitted an FPI when clearing a bit? But I'm
unsure that that was required at the time. OTOH, it did seem to generate an
FPI for setting a VM bit, so ...

Greetings,

Andres Freund