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

On Thu, Jul 16, 2026 at 6:58 AM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
>
> On Tue, Jul 14, 2026 at 3:42 PM Melanie Plageman
> <melanieplageman(at)gmail(dot)com> wrote:
> >
> > I've also finished all branch versions of this. Each one's code
> > differs, but I've managed to keep the commit messages the same, which
> > should help release notes. Note that REL_19_STABLE bumps
> > XLOG_PAGE_MAGIC. This would keep us from having to maintain the
> > backwards compatibility code there, which I think is what we want.
> > Here are those branches.
>
> I've pushed the main commits to all branches where needed.

Thanks for working on them!

In commit ed62d26caca

- if (!BufferIsValid(vmbuf) || BufferGetBlockNumber(vmbuf) != mapBlock)
- elog(ERROR, "wrong buffer passed to visibilitymap_clear");
+ Assert(BufferIsValid(vmbuf) && BufferGetBlockNumber(vmbuf) == mapBlock);

Isn't it be better to keep the elog(ERROR) in addition to the Assert()
so that wrong buffer is detected even in non-assert builds?

Otherwise, a non-assert build could silently modify the wrong VM page
if a caller passes the wrong buffer. Since this commit increased the number
of callers and introduced visibilitymap_clear() into WAL redo paths,
it seems safer to retain the runtime check.

Regards,

--
Fujii Masao