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

From: Melanie Plageman <melanieplageman(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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>, Andres Freund <andres(at)anarazel(dot)de>, 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-08-04 22:13:21
Message-ID: CAAKRu_ammwSQityMfSPcyj7h5UMM1BAugzEce=icbGKgf5yMzA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 20, 2026 at 10:56 AM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
>
> On Sun, Jul 19, 2026 at 10:34 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >
> > Melanie Plageman <melanieplageman(at)gmail(dot)com> writes:
> > > I've committed this.
> >
> > Coverity complained about this patch:
> >
> > /srv/coverity/git/pgsql-git/postgresql/src/backend/access/heap/pruneheap.c: 951 in heap_page_fix_vm_corruption()
> > 945 MarkBufferDirtyHint(prstate->buffer, true);
> > 946 }
> > 947
> > 948 if (do_clear_vm)
> > 949 {
> > 950 LockBuffer(prstate->vmbuffer, BUFFER_LOCK_EXCLUSIVE);
> > >>> CID 1697133: Error handling issues (CHECKED_RETURN)
> > >>> Calling "visibilitymap_clear" without checking return value (as is done elsewhere 13 out of 14 times).
> > 951 visibilitymap_clear(prstate->relation->rd_locator, prstate->block,
> > 952 prstate->vmbuffer,
> > 953 VISIBILITYMAP_VALID_BITS);
> > 954 LockBuffer(prstate->vmbuffer, BUFFER_LOCK_UNLOCK);
> > 955 prstate->old_vmbits = 0;
> > 956 }
> >
> > I think it's right to complain --- if we check for failure everywhere
> > else, why's it OK to not check here? If it is OK, a comment and an
> > explicit cast to "(void)" would be appropriate.
>
> Got it. I didn't know we always checked return values everywhere in
> the code base.
>
> In other cases where we call visibilitymap_clear(), we use the return
> value to decide whether or not to emit WAL (because if the page wasn't
> modified, we shouldn't). Not emitting WAL here is its own questionable
> issue (historical, not something I introduced), but since we don't, I
> didn't need the return value. I'll push a comment and cast next week
> (I'm traveling this week and don't commit on the road if I can help
> it).

K, I committed this to 19 and master. In backbranches we actually
check the return value even less -- coverity was complaining because
we started checking the return value more often and it went over some
threshold.

- Melanie

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2026-08-04 22:20:00 Re: Report index currently being vacuumed in pg_stat_progress_vacuum
Previous Message Michael Paquier 2026-08-04 21:59:58 Re: Bug: XLogReader mishandles oversized multi-page xl_tot_len (potential memory corruption)