Re: Backend stuck in tirigger.c:afterTriggerInvokeEvents forever

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Backend stuck in tirigger.c:afterTriggerInvokeEvents forever
Дата
Msg-id 20200421151935.GA18772@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: Backend stuck in tirigger.c:afterTriggerInvokeEvents forever  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Backend stuck in tirigger.c:afterTriggerInvokeEvents forever  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Backend stuck in tirigger.c:afterTriggerInvokeEvents forever  (Andres Freund <andres@anarazel.de>)
Список pgsql-bugs
On 2020-Apr-21, Tom Lane wrote:

> A variant of that theory is that foreign key trigger firings are being
> skipped in one case but not the other; but offhand I think those
> optimizations only apply to update/delete cases not inserts.  Anyway
> that still requires some assumptions about moving parts that you
> haven't shown us.

I wonder if there are any funny interactions between trigger tuple
acquisition and the ON CONFLICT stuff.  The only thing that occurs to me
to explain the fact that it only fails with the two stmts in the DO
block is that the second insert can see rows as inserted by the same
transaction.

I would start by taking a few dozen backtraces and comparing them to see
if any progress is being made.

The fact that this reproduces in 11.2 would seem to discard theories
about tuple table slot changes and table AM.

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



В списке pgsql-bugs по дате отправления:

Предыдущее
От: cbw
Дата:
Сообщение: Re: Backend stuck in tirigger.c:afterTriggerInvokeEvents forever
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Backend stuck in tirigger.c:afterTriggerInvokeEvents forever