Re: algo for canceling a deadlocked transaction

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: algo for canceling a deadlocked transaction
Дата
Msg-id 14199.1523286244@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: algo for canceling a deadlocked transaction  (Christophe Pettus <xof@thebuild.com>)
Ответы Re: algo for canceling a deadlocked transaction  (Thomas Poty <thomas.poty@gmail.com>)
Список pgsql-general
Christophe Pettus <xof@thebuild.com> writes:
>> On Apr 9, 2018, at 07:33, Thomas Poty <thomas.poty@gmail.com> wrote:
>> ok, and long  answer ? is it random?

> It's not literally random, but from the application point of view, it's not predictable.  For example, it's not
alwaysthe one that opened first, or any other consistent measure. 

It's whichever one runs the deadlock detector first after the circular
wait becomes established.  For instance:

* Process A takes lock L1

* Process B takes lock L2

* Process A tries to take lock L2, blocks

* Process B tries to take lock L1, blocks (now a deadlock exists)

Process A will run the deadlock detector one deadlock_timeout after
blocking.  If that happens before B has blocked, then A will see
no deadlock and will go back to waiting.  In that case, when B's
own deadlock_timeout expires and it runs the deadlock detector,
it will see the deadlock and fix it by canceling its own wait.
On the other hand, if B started to wait less than one deadlock_timeout
after A did, then A will be first to observe the deadlock and it will
cancel itself, not B.

So you can't predict it unless you have a lot of knowledge about
the timing of events.  You could probably make it more predictable
by making deadlock_timeout either very short or very long, but
neither of those are desirable things to do.

            regards, tom lane


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

Предыдущее
От: Christophe Pettus
Дата:
Сообщение: Re: algo for canceling a deadlocked transaction
Следующее
От: Mark Moellering
Дата:
Сообщение: best way to write large data-streams quickly?