Re: Assertion failure in REL9_5_STABLE
| От | Marko Tiikkaja |
|---|---|
| Тема | Re: Assertion failure in REL9_5_STABLE |
| Дата | |
| Msg-id | 6d9bc80f-3e47-c951-18fd-ab514d30655d@joh.to обсуждение исходный текст |
| Ответ на | Re: Assertion failure in REL9_5_STABLE (Alvaro Herrera <alvherre@2ndquadrant.com>) |
| Ответы |
Re: Assertion failure in REL9_5_STABLE
|
| Список | 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 по дате отправления: