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

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

Бэкенд может только сделать харакири. Он не может прибить чужую транзакцию.

Но умирает же одна из двух (3-ёх и т.д.), т.е. как-то же определяется, кто именно.

Если бэкенд определяет и оба бэкенда на разных ядрах, то тогда есть вероятность, что обе умрут.

Логика работы deadlock детектора в ПГ очень простая - если я не могу получить лок в течении какого-то времени (deadlock detection timeout), то лочу всё и ищу в графе циклы. Если нашёл - бросаю ошибку и завершаю транзакцию.

Понятно, спасибо.

Тогда получается, что с 3-мя сессиями в pg можно livelock получить, а Ярослав, скорей всего имел ввиду, что выбирать нужно кем-то, а не кому повезёт.

Кстати, а как правильно говорить livelock или starvation в данном случае?

Добрый день, товарищи! Подскажите, пожалуйста, можно ли прикрутить pgbackrest к какой-нибудь web-морде для удобства администрирования?

Поиск цикла в графе делается под эксклюзивной блокировкой. Вероятность того, что оба участника дедлока решат  сделать харакири достаточно мала.
Но есть другая более реальная проблема, которую мы действительно наблюдали.
И, вспомнив про неё, я склонен согласится, что в дедлок дететоре посгреса действительно есть деффект.
Под большой нагрузкой, если много транзакций конфликтуют за один и тот же ресурс (например table extension lock), то все они засыпают на этом локе и ... таймаут в них срабатывает примерно в одно и тоже  время. И все они начинают искать дедлок, для этого пытая взять ксклюзивную блокировку. И... Всё практически  встаёт.
Мы в ПгПро испытали несколько способов решить эту проблему:
1. Пытаться преварительно проверить наличие дедлка под шаред блокировкой.
2. Если кто-то уже ищет циклы в графе, то запретить ругим бэкендам заниматься дедлок детекшином
3. Запоминать в рётрах графа блокировки время последнего прохода и не ходить повторно по ним в течении какого-то времени

Здравствуйте! Подскажите, пожалуйста, как грамотно решить проблему планирования осуществления некоторых действий для нескольких БД в одном кластере? Просто pg_cron может работать только для одной БД, к сожалению.

Потому что СУБД сама сделать это неспособна, очевидно.

Похоже на то, да. Но для RR и S — это обычная ситуация, а вот serialization failures на RC до этого, кажется, не было.

В принципе способна, для одностайтментовых транзакций. Другое дело - есть ли в этом большой смысл... И еасколько хорошо  по разному вести себя на "простых "и "сложных" транзакциях.

Выбираться может случайная сессия — вот в чём проблема.
Т.е., к примеру, есть сессии приложений 1 и 2, которые выполняют длинные транзакции, систематически попадающие в deadlock. Дальше происходит следующее: PostgreSQL откатывает 1, она повторяется приложением 2 — опять deadlock, но PostgreSQL откатывает 2, повторяется 1 — опять deadlock, PostgreSQL откатывает 1... и где-то всё это мы уже видели (потенциально, это может продолжаться бесконечно). И это starvation.

> Поиск цикла в графе делается под эксклюзивной блокировкой. Вероятность того, что оба участника дедлока решат  сделать харакири достаточно мала.

Я думал, что если один из участников дедлока ищет, то после поиска он делает так, чтобы его больше в этом цикле в графе небыло. Тогда второй протсо не будет умирать, так как после unlock-а граф будет без цикла.
Ну да ладно.

То, что вы описали, не предотвращает livelock с 3 сессиями:
Вот пример:

    ses 1|ses 2 |ses 3
--------------------------
t1| row 1| row 2| row 3
t2| row 2| row 3| row 1
t3| row 3| row 1| row 2

Первая сессия берёт последовательно блокировку на строки 1, 2, 3 в разные моменты времени, второая - на эти эти же строки, но в порядке 2, 3, 1 и т.д.

Если умирать будет не самый подходящий бэкенд, то после повтора будет livelock.

Ещё одна "декларация". ;) Обсуждали уже выше.

Почему нельзя запоминать выполненные стейтменты? И выполнять надо для определённых видов ошибок...

Ага, я примерно тоже самое описал, но с 3-мя транзакциями.
С двумя транзакциями тоже можно придумать, да.

Чего только выше нет! А эта декларация проверяется калькулятором  или даже листочком с ручкой. Надо только примерно прикинуть при каком значении deadlock_timeout и примерной вероятности дедлока бекенды перестанут успевать обслуживать клиентов.

Уже написал про проблему. В других СУБД есть какой-то приоритет при ROLLBACK — в описанной ситуации всегда будет откатываться транзакции сессии 2, например. Поэтому прогресс гарантирован.

> Starvation - это не проблема постгресового дедлок детектора, а приложения

Нет, это именно низкокачественная реализация (потому что, опять-таки, проблема описана в учебниках по transaction processing, там приводятся "классические" решения (prioritizing), и то, что PostgreSQL их не реализует, характеризует его как-то так, IMNSHO). И приложение должно так с ними справляться.