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