Assertion failure in REL9_5_STABLE
От | Marko Tiikkaja |
---|---|
Тема | Assertion failure in REL9_5_STABLE |
Дата | |
Msg-id | 48d3eade-98d3-8b9a-477e-1a8dc32a724d@joh.to обсуждение исходный текст |
Ответы |
Re: Assertion failure in REL9_5_STABLE
Re: Assertion failure in REL9_5_STABLE Re: Assertion failure in REL9_5_STABLE Re: Assertion failure in REL9_5_STABLE |
Список | 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@entry=0x7effb5b27a88 "!(CritSectionCount > 0 || TransactionIdIsCurrentTransactionId(( (!((tup)->t_infomask & 0x0800) && ((tup)->t_infomask & 0x1000) && !((tup)->t_infomask & 0x0080)) ? HeapTupleGetUpdateXid(tup) : ( (tup)-"..., errorType=errorType@entry=0x7effb599b74b "FailedAssertion", fileName=fileName@entry=0x7effb5b2796c "combocid.c", lineNumber=lineNumber@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@entry=0x7fffcee73690, cid=346, mode=mode@entry=LockTupleExclusive, wait_policy=LockWaitBlock, follow_updates=follow_updates@entry=1 '\001', buffer=buffer@entry=0x7fffcee7367c, hufd=hufd@entry=0x7fffcee73680) at heapam.c:4813 #5 0x00007effb5753e82 in ExecLockRows (node=node@entry=0x7effb6cebb00) at nodeLockRows.c:179 #6 0x00007effb573cbc8 in ExecProcNode (node=node@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
Вложения
В списке pgsql-hackers по дате отправления: