Re: Assertion failure in REL9_5_STABLE
От | Alvaro Herrera |
---|---|
Тема | Re: Assertion failure in REL9_5_STABLE |
Дата | |
Msg-id | 20160810172840.GA607008@alvherre.pgsql обсуждение исходный текст |
Ответ на | Assertion failure in REL9_5_STABLE (Marko Tiikkaja <marko@joh.to>) |
Ответы |
Re: Assertion failure in REL9_5_STABLE
|
Список | pgsql-hackers |
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@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 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
В списке pgsql-hackers по дате отправления: