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

From: Andres Freund <andres(at)anarazel(dot)de>
To: Melanie Plageman <melanieplageman(at)gmail(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: Why clearing the VM doesn't require registering vm buffer in wal record
Date: 2026-07-17 21:18:18
Message-ID: lobxyb23d4vhb6e2mpfgmk5jhegthrxqi6x2opozbsnbltajo4@a3g4jpequog6
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2026-07-16 18:35:30 -0400, Melanie Plageman wrote:
> On Wed, Jul 15, 2026 at 9:31 PM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> > - 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.
>
> I had a vague memory of discussing this with someone at some point
> (and that person agreeing we should turn the error into an assert) but
> now I can't find any record of it.

That might have been me.

I don't see any reason for this to be an elog(). So much would have to go
wrong for that to happen in a non-assert build. And we check many more crucial
things only in Asserts.

I'm also don't care too much about it being an elog, so I'm not going to push
for reverting the s/Assert/elog/. But I don't think it should be seen any sort
of policy about this kind of check needing to be an elog going forward.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zsolt Parragi 2026-07-17 21:26:10 Re: [PATCH] Add pg_get_event_trigger_ddl() function
Previous Message Zsolt Parragi 2026-07-17 21:16:23 Re: SLOPE - Planner optimizations on monotonic expressions.