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
