Re: Assertion failure in REL9_5_STABLE

Marko Tiikkaja wrote:
> 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

Umm. AFAICS HeapTupleSatisfiesUpdate() only returns SelfUpdated after
already calling HeapTupleHeaderGetCmax() (which obviously hasn't caught
the same assertion). Something is odd there ...

Can you share the test case?

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services