database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-09 22:41:56 +03:00
Code Activity

Avoid harmless Valgrind no-buffer-pin errors.

Browse Source 
Valgrind builds with assertions enabled sometimes perform a
theoretically unsafe page access inside an assertion in
heapam_tuple_lock().  This happened when the eval-plan-qual isolation
test ran one of the permutations added by commit a2418f9e23.

Avoid complaints from Valgrind by moving the assertion ever so slightly.
This is minor cleanup for commit 1e0dfd16, which added Valgrind buffer
access instrumentation.

No backpatch, since this only happens within an assertion, and seems
very unlikely to cause any real problems even with assert-enabled
builds.
This commit is contained in:
Peter Geoghegan
2020-07-19 16:12:51 -07:00
parent 46ef520b95
commit a766d6ca22
1 changed files with 2 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
src/backend/access/heap/heapam_handler.c
View File

@ -368,10 +368,11 @@ tuple_lock_retry:
if (result == TM_Updated && if (result == TM_Updated &&
(flags & TUPLE_LOCK_FLAG_FIND_LAST_VERSION)) (flags & TUPLE_LOCK_FLAG_FIND_LAST_VERSION))
{ {
ReleaseBuffer(buffer);
/* Should not encounter speculative tuple on recheck */ /* Should not encounter speculative tuple on recheck */
Assert(!HeapTupleHeaderIsSpeculative(tuple->t_data)); Assert(!HeapTupleHeaderIsSpeculative(tuple->t_data));
ReleaseBuffer(buffer);
if (!ItemPointerEquals(&tmfd->ctid, &tuple->t_self)) if (!ItemPointerEquals(&tmfd->ctid, &tuple->t_self))
{ {
SnapshotData SnapshotDirty; SnapshotData SnapshotDirty;