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 a2418f9e238.

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.

diff --git a/src/backend/access/heap/heapam_handler.c b/src/backend/access/heap/heapam_handler.c
index 56b35622f1a4faa6bcd4d2de6b304fedee5482e0..8f2e5379210ca328d6e3f0c18bdd0d87be3b112f 100644 (file)
--- a/src/backend/access/heap/heapam_handler.c
+++ b/src/backend/access/heap/heapam_handler.c
@@ -368,10 +368,11 @@ tuple_lock_retry:
        if (result == TM_Updated &&
                (flags & TUPLE_LOCK_FLAG_FIND_LAST_VERSION))
        {
-               ReleaseBuffer(buffer);
                /* Should not encounter speculative tuple on recheck */
                Assert(!HeapTupleHeaderIsSpeculative(tuple->t_data));
 
+               ReleaseBuffer(buffer);
+
                if (!ItemPointerEquals(&tmfd->ctid, &tuple->t_self))
                {
                        SnapshotData SnapshotDirty;