Re: Assertion failure in REL9_5_STABLE - Mailing list pgsql-hackers

From Marko Tiikkaja
Subject Re: Assertion failure in REL9_5_STABLE
Date
Msg-id 6d9bc80f-3e47-c951-18fd-ab514d30655d@joh.to
Whole thread Raw
In response to Re: Assertion failure in REL9_5_STABLE  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Assertion failure in REL9_5_STABLE  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On 2016-08-10 19:28, Alvaro Herrera wrote:
> Umm.  AFAICS HeapTupleSatisfiesUpdate() only returns SelfUpdated after
> already calling HeapTupleHeaderGetCmax() (which obviously hasn't caught
> the same assertion).  Something is odd there ...

HeapTupleSatisfiesUpdate() returns HeapTupleBeingUpdated in this case. 
HeapTupleSelfUpdated comes from here (line 4749):
    /* if there are updates, follow the update chain */    if (follow_updates && !HEAP_XMAX_IS_LOCKED_ONLY(infomask))
{        HTSU_Result res;        res = heap_lock_updated_tuple(relation, tuple, &t_ctid,
     GetCurrentTransactionId(),                                      mode);        if (res != HeapTupleMayBeUpdated)
   {            result = res;            /* recovery code expects to have buffer lock held */
LockBuffer(*buffer,BUFFER_LOCK_EXCLUSIVE);            goto failed;         }     }
 

> Can you share the test case?

Not at this time, sorry.


.m



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: new pgindent run before branch?
Next
From: Peter Geoghegan
Date:
Subject: Re: Parallel tuplesort, partitioning, merging, and the future