Re: Why clearing the VM doesn't require registering vm buffer in wal record - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Why clearing the VM doesn't require registering vm buffer in wal record
Date
Msg-id 1065814.1784514869@sss.pgh.pa.us
Whole thread
In response to Re: Why clearing the VM doesn't require registering vm buffer in wal record  (Melanie Plageman <melanieplageman@gmail.com>)
Responses Re: Why clearing the VM doesn't require registering vm buffer in wal record
List pgsql-hackers
Melanie Plageman <melanieplageman@gmail.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



pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Support EXCEPT for TABLES IN SCHEMA publications
Next
From: Tatsuya Kawata
Date:
Subject: Re: Allow wal_log_hints to be changed without restart