Assertion failure in REL9_5_STABLE

From: Marko Tiikkaja <marko(at)joh(dot)to>
To: Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Assertion failure in REL9_5_STABLE
Date: 2016-08-10 16:27:12
Message-ID: 48d3eade-98d3-8b9a-477e-1a8dc32a724d@joh.to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Running one specific test from our application against REL9_5_STABLE
(current as of today) gives me this:

#2 0x00007effb59595be in ExceptionalCondition (
conditionName=conditionName(at)entry=0x7effb5b27a88
"!(CritSectionCount > 0 || TransactionIdIsCurrentTransactionId((
(!((tup)->t_infomask & 0x0800) && ((tup)->t_infomask & 0x1000) &&
!((tup)->t_infomask & 0x0080)) ? HeapTupleGetUpdateXid(tup) : (
(tup)-"..., errorType=errorType(at)entry=0x7effb599b74b "FailedAssertion",
fileName=fileName(at)entry=0x7effb5b2796c "combocid.c",
lineNumber=lineNumber(at)entry=132) at assert.c:54
#3 0x00007effb598e19b in HeapTupleHeaderGetCmax (tup=0x7effa85714c8) at
combocid.c:131
#4 0x00007effb55fb0c1 in heap_lock_tuple (relation=0x7effb5bf5d90,
tuple=tuple(at)entry=0x7fffcee73690, cid=346,
mode=mode(at)entry=LockTupleExclusive, wait_policy=LockWaitBlock,
follow_updates=follow_updates(at)entry=1 '\001',
buffer=buffer(at)entry=0x7fffcee7367c, hufd=hufd(at)entry=0x7fffcee73680)
at heapam.c:4813
#5 0x00007effb5753e82 in ExecLockRows (node=node(at)entry=0x7effb6cebb00)
at nodeLockRows.c:179
#6 0x00007effb573cbc8 in ExecProcNode (node=node(at)entry=0x7effb6cebb00)
at execProcnode.c:516
#7 0x00007effb5739432 in ExecutePlan (dest=0x7effb5dd8160
<spi_printtupDR>, direction=<optimized out>, numberTuples=0,
sendTuples=1 '\001', operation=CMD_SELECT, planstate=0x7effb6cebb00,
estate=0x7effb6ceb8f8)
at execMain.c:1549
#8 standard_ExecutorRun (queryDesc=0x7effb6ae3b40, direction=<optimized
out>, count=0) at execMain.c:337
#9 0x00007effb57661db in _SPI_pquery (tcount=0, fire_triggers=1 '\001',
queryDesc=0x7effb6ae3b40) at spi.c:2411

The failure is a number of levels down a call stack of PL/PgSQL
functions, but I can reproduce it at will by calling the function. I
unfortunately can't narrow it down to a smaller test case, but attached
is an xlogdump of the session. The query that finally breaks the
elephant's back is a SELECT .. FOR UPDATE from relid=54511.

Any ideas on how to debug this?

.m

Attachment Content-Type Size
assert.xlog text/plain 63.0 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ants Aasma 2016-08-10 16:38:32 Re: Proposal for CSN based snapshots
Previous Message Joshua D. Drake 2016-08-10 16:24:22 Re: Proposal for CSN based snapshots