Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit a766d6c

Browse files
Avoid harmless Valgrind no-buffer-pin errors.
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 a2418f9. Avoid complaints from Valgrind by moving the assertion ever so slightly. This is minor cleanup for commit 1e0dfd1, 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.
1 parent 46ef520 commit a766d6c

File tree

1 file changed

+2
-1
lines changed

1 file changed

+2
-1
lines changed

src/backend/access/heap/heapam_handler.c

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -368,10 +368,11 @@ heapam_tuple_lock(Relation relation, ItemPointer tid, Snapshot snapshot,
368368
if (result == TM_Updated &&
369369
(flags & TUPLE_LOCK_FLAG_FIND_LAST_VERSION))
370370
{
371-
ReleaseBuffer(buffer);
372371
/* Should not encounter speculative tuple on recheck */
373372
Assert(!HeapTupleHeaderIsSpeculative(tuple->t_data));
374373

374+
ReleaseBuffer(buffer);
375+
375376
if (!ItemPointerEquals(&tmfd->ctid, &tuple->t_self))
376377
{
377378
SnapshotData SnapshotDirty;

0 commit comments

Comments
 (0)