А в чём проблема с deadlock detection в PG и

Question

А в чём проблема с deadlock detection в PG и

чем он отличается от "правильного" в других СУБД?
Избежать дедлоков можно если на момент старта транзакции известен весь набор блокировок, которые она затребует. Это модель более менее работает в случае одного SQL statement-а, но совершенно не подходит для транзакции, логика работы которой управляется приложением (например написанной на PL/pgSQL)
Starvation - это не проблема постгресового дедлок детектора, а приложения, которое пытается справится с дедлоками путём повторения транзакции. Но, кстати, на мой взгляд, это вполне нормальная стратегия, если вероятность конфликта маленькая.

#backend #devops #pgsql #programming #russian

0

19.05.2020

2 ответов

13 просмотров

Yaroslav Schekin

Уже написал про проблему. В других СУБД есть какой-то приоритет при ROLLBACK — в описанной ситуации всегда будет откатываться транзакции сессии 2, например. Поэтому прогресс гарантирован. > Starvation - это не проблема постгресового дедлок детектора, а приложения Нет, это именно низкокачественная реализация (потому что, опять-таки, проблема описана в учебниках по transaction processing, там приводятся "классические" решения (prioritizing), и то, что PostgreSQL их не реализует, характеризует его как-то так, IMNSHO). И приложение должно так с ними справляться.

0

19.05.2020

Aleksey Stavrov · Accepted Answer

Aleksey Stavrov

А как PG определяет, какую из транзакции он откатит в случае deadlock детекта?

0

19.05.2020

172 похожих чатов

А в чём проблема с deadlock detection в PG и

2 ответов

Похожие вопросы