Re: algo for canceling a deadlocked transaction
От | Thomas Poty |
---|---|
Тема | Re: algo for canceling a deadlocked transaction |
Дата | |
Msg-id | CAN_ctniAhCaDdTdmtvr9u37dsp7W9nt49bOS6uGoMV7Z4g9tJg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: algo for canceling a deadlocked transaction (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: algo for canceling a deadlocked transaction
|
Список | pgsql-general |
Hello Stephen,
> The short answer is "it's whichever one detected the deadlock." The
> deadlock timeout fires after a lock has been held that long and if a
> deadlock is detected then the process detecting it will be canceled.
ok, and long answer ? is it random?> The short answer is "it's whichever one detected the deadlock." The
> deadlock timeout fires after a lock has been held that long and if a
> deadlock is detected then the process detecting it will be canceled.
> I'd strongly recommend reviewing your application and addressing
> deadlocks by changing how the application acquires locks to be
> consistent and to avoid lock escalation instead of worrying about how to
> predict a deadlock- a properly designed and written application
> shouldn't be causing deadlocks to happen in the first place.
Thank you
2018-04-09 15:51 GMT+02:00 Stephen Frost <sfrost@snowman.net>:
Greetings,
* Thomas Poty (thomas.poty@gmail.com) wrote:
> My question is : In case of a deadlock between 2 transaction, how to know
> which transaction will be canceled? Is it predictable?
The short answer is "it's whichever one detected the deadlock." The
deadlock timeout fires after a lock has been held that long and if a
deadlock is detected then the process detecting it will be canceled.
I'd strongly recommend reviewing your application and addressing
deadlocks by changing how the application acquires locks to be
consistent and to avoid lock escalation instead of worrying about how to
predict a deadlock- a properly designed and written application
shouldn't be causing deadlocks to happen in the first place.
Thanks!
Stephen
В списке pgsql-general по дате отправления: