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

On 21 Sep 2026, Melanie Plageman wrote:
> That wouldn't help in this case because it was already clear on the
> primary.

Yes, my suggestion was too vague. I meant a check during redo that
would fail an assert-enabled buildfarm run and preserve enough state
to investigate. A WARNING can go unnoticed in a passing TAP test, as
David recently pointed out [0]. Could we make this fatal in assert
builds, once we have a condition that excludes pages legitimately
ahead of replay?

In heap_xlog_vm_clear_unregistered(), couldn't the VM page already have
a newer LSN? Consider a heap record R whose VM clear was a no-op,
followed by VACUUM setting that bit at S. If the VM page at S reaches
disk and crash recovery starts before R, the new helper would call this
corruption and move the page LSN backwards to R. Unlike
XLogReadBufferForRedo(), it does not check the page LSN. I did not
reproduce this, just seems possible.

Could we retain the original VM bits and page LSN in the diagnostic?
The WAL redo CONTEXT already identifies the record. A page-LSN check
also needs care: another heap block's bit can advance the same VM page's
LSN without repairing the bit we are interested in.

Also, if we accept a possible torn page from this repair, what happens
on the next recovery? The new reader uses RBM_NORMAL_NO_LOG, not the
VM's usual RBM_ZERO_ON_ERROR, so a checksum failure could stop recovery
before it gets to the repair.

For this repair, shouldn't we either use RBM_ZERO_ON_ERROR on every
relevant recovery read path, or require an FPI for the VM page since
the last checkpoint's redo point before allowing the modification?

There are quite a few moving parts in VM, and I don't yet have a clear
picture of how they all fit together. Sorry if some of these questions
are a distraction. I have a handful of open tickets about VM corruption,
and I hope we can track down and fix all possible issues.

Thank you!

Best regards, Andrey Borodin.

[0] https://www.postgresql.org/message-id/CAApHDvp4Oi4EuNixzR-mynNi4mKpVNsvbCDkNA_-yEtu-BeA3w%40mail.gmail.com