From: | Marko Tiikkaja <marko(at)joh(dot)to> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Assertion failure in REL9_5_STABLE |
Date: | 2016-08-10 20:47:15 |
Message-ID: | 6d9bc80f-3e47-c951-18fd-ab514d30655d@joh.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2016-08-10 20:54:32 | Re: Parallel tuplesort, partitioning, merging, and the future |
Previous Message | Bruce Momjian | 2016-08-10 20:44:12 | Re: new pgindent run before branch? |