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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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>, 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-07-20 02:34:29
Message-ID: 1065814.1784514869@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alena Vinter 2026-07-20 02:46:01 Re: pg_rewind WAL segments deletion pitfall
Previous Message Peter Smith 2026-07-20 02:20:46 Re: Support EXCEPT for TABLES IN SCHEMA publications