BUG #5914: locking error in heap_fetch

The following bug has been logged online:

Bug reference: 5914
Logged by: YAMAMOTO Takashi
Email address: yamt(at)mwd(dot)biglobe(dot)ne(dot)jp
PostgreSQL version: 9.1devel
Operating system: NetBSD
Description: locking error in heap_fetch
Details:

heap_fetch calls CheckForSerializableConflictOut without buffer locked.
it ends up an assertion failure in SetBufferCommitInfoNeedsSave.

diff --git a/src/backend/access/heap/heapam.c
b/src/backend/access/heap/heapam.c
index 7dcc601..89697f6 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -1472,10 +1472,10 @@ heap_fetch(Relation relation,
if (valid)
PredicateLockTuple(relation, tuple);

- LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
-
CheckForSerializableConflictOut(valid, relation, tuple, buffer);

+ LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
+
if (valid)
{
/*

(gdb) bt
#0 0xbbba4cc7 in _lwp_kill () from /usr/lib/libc.so.12
#1 0xbbba4c85 in raise (s=6) at /siro/nbsd/src/lib/libc/gen/raise.c:48
#2 0xbbba445a in abort () at /siro/nbsd/src/lib/libc/stdlib/abort.c:74
#3 0x083dae20 in ExceptionalCondition (
conditionName=0x8546fa4 "!(LWLockHeldByMe(bufHdr->content_lock))",
errorType=0x8546d04 "FailedAssertion", fileName=0x8546cfb "bufmgr.c",
lineNumber=2279) at assert.c:57
#4 0x082cb599 in SetBufferCommitInfoNeedsSave (buffer=633) at
bufmgr.c:2279
#5 0x0840b8e0 in SetHintBits (tuple=0x9b72efd0, buffer=633, infomask=256,
xid=154311) at tqual.c:121
#6 0x0840d614 in HeapTupleSatisfiesVacuum (tuple=0x9b72efd0,
OldestXmin=154312, buffer=633) at tqual.c:1128
#7 0x082ea867 in CheckForSerializableConflictOut (visible=1 '\001',
relation=0x99b5fcf8, tuple=0xbfbfdee4, buffer=633) at predicate.c:3402
#8 0x080a8c67 in heap_fetch (relation=0x99b5fcf8, snapshot=0x85949a0,
tuple=0xbfbfdee4, userbuf=0xbfbfdecc, keep_buf=0 '\0',
stats_relation=0x0)
at heapam.c:1477
#9 0x081d0174 in AfterTriggerExecute (event=0x99a19044, rel=0x99b5fcf8,
trigdesc=0x99a05110, finfo=0x99a05450, instr=0x99a05588,
per_tuple_context=0x99b32a50) at trigger.c:3311
#10 0x081d05f2 in afterTriggerInvokeEvents (events=0x99a01120, firing_id=1,
estate=0x99a0501c, delete_ok=1 '\001') at trigger.c:3531
#11 0x081d09df in AfterTriggerEndQuery (estate=0x99a0501c) at
trigger.c:3721
#12 0x081e8afa in standard_ExecutorFinish (queryDesc=0x99b358bc)
at execMain.c:383
#13 0x081e89db in ExecutorFinish (queryDesc=0x99b358bc) at execMain.c:351
#14 0x082f73c2 in ProcessQuery (plan=0x99ba8c4c,
sourceText=0x99b3581c "DELETE FROM file WHERE fileid = $1",
params=0x99b3587c, dest=0x858ef9c, completionTag=0xbfbfe1f0 "DELETE 1")
at pquery.c:227
#15 0x082f8837 in PortalRunMulti (portal=0x99b3d01c, isTopLevel=1 '\001',
dest=0x858ef9c, altdest=0x858ef9c, completionTag=0xbfbfe1f0 "DELETE 1")
at pquery.c:1276
#16 0x082f7ffe in PortalRun (portal=0x99b3d01c, count=2147483647,
isTopLevel=1 '\001', dest=0x99b05428, altdest=0x99b05428,
completionTag=0xbfbfe1f0 "DELETE 1") at pquery.c:813
#17 0x082f3df1 in exec_execute_message (portal_name=0x99b0501c "",
max_rows=2147483647) at postgres.c:1963
#18 0x082f6709 in PostgresMain (argc=2, argv=0xbb9126a4,
username=0xbb9125f8 "takashi") at postgres.c:3959
#19 0x082a81cb in BackendRun (port=0xbb94c0f0) at postmaster.c:3590
#20 0x082a788f in BackendStartup (port=0xbb94c0f0) at postmaster.c:3275
#21 0x082a4b0f in ServerLoop () at postmaster.c:1449
#22 0x082a42be in PostmasterMain (argc=3, argv=0xbfbfe5a8) at
postmaster.c:1110
#23 0x08225618 in main (argc=3, argv=0xbfbfe5a8) at main.c:199
(gdb)