У одного клиента возникает неприятная ситуация. Есть две операции, каждая из которых выполняет значительный объем update'ов, причем по определенным причинам в недетерминированном порядке. Это приводит к dead-lock'ам, видя которые СУБД перестартует одну из транзакций. Но при этом получается следующая ситуация : первая транзакция дедлочит вторую, вторая перестартует, опять попадает в дедлок с первой и на этот раз постгрес перестартует первую, она в свою очередь дедлочит вторую и так по кругу (то есть в логе я вижу по 25 дедлоков у каждого процесса). Соответственно вопрос:

1) Какой приоритет по умолчанию при выборе жертвы дедлока?

2) Можно ли как-то управлять этим приоритетом? То есть скажем выбирать жертвой самую юную транзакцию (собственно это самое логично поведение, непонятно почему оно не используется).

ЗЫ: В гугле практически ничего нет, все ссылки на MS SQL, где для дедлоков кучу настроек, но там и понятно что проблема острее, блокировочник как никак.

MelkijЕсли вам всё равно можно убивать транзакцию, то есть устраивает последовательная, а не конкурентная работа, то может последовательную работу и сделать? Получить, например, advisory lock в начале транзакции, сделать всё что нужно, дать поработать следующему потоку.
https://www.postgresql.org/docs/current/static/functions-admin.html#FUNCTIONS-ADVISORY-LOCKS

Потому что заранее не известно, будет dead lock или нет.

Maxim BogukNitro_JunkieУ одного клиента возникает неприятная ситуация. Есть две операции, каждая из которых выполняет значительный объем update'ов, причем по определенным причинам в недетерминированном порядке. Это приводит к dead-lock'ам, видя которые СУБД перестартует одну из транзакций. Но при этом получается следующая ситуация : первая транзакция дедлочит вторую, вторая перестартует, опять попадает в дедлок с первой и на этот раз постгрес перестартует первую, она в свою очередь дедлочит вторую и так по кругу (то есть в логе я вижу по 25 дедлоков у каждого процесса). Соответственно вопрос:

1) Какой приоритет по умолчанию при выборе жертвы дедлока?

2) Можно ли как-то управлять этим приоритетом? То есть скажем выбирать жертвой самую юную транзакцию (собственно это самое логично поведение, непонятно почему оно не используется).

ЗЫ: В гугле практически ничего нет, все ссылки на MS SQL, где для дедлоков кучу настроек, но там и понятно что проблема острее, блокировочник как никак.

begin;
set local deadlock_timeout to '60s';
ваша транзакция...
...
commit;

у какой транзакции deadlock_timeout выше у той и приоритет выше (т.е. ее не будут стрелять пока все с меньшим не пристрелят).
костыль конечно но работающий воспроизводимо.


--
Maxim Boguk
www.postgresql-consulting.ru

А она точно scope'та к текущему соединению? Но вообще идея интересная, спасибо, будем пробовать.

Maxim BogukNitro_Junkieпропущено...


А она точно scope'та к текущему соединению? Но вообще идея интересная, спасибо, будем пробовать.

alter system - глобальная смена настроек
set - к текущему соединению
set local - к текущей транзакции

--
Maxim Boguk
www.postgresql-consulting.ru

Не, я к тому что не все же настройки можно так scope'ить. И непонятно как определить какие настройки можно переопределять для соединения, а какие нет.

PgSQLanonymous2Maxim Bogukу какой транзакции deadlock_timeout выше у той и приоритет выше (т.е. ее не будут стрелять пока все с меньшим не пристрелят).
костыль конечно но работающий воспроизводимо.


Но "Only superusers can change this setting." Так что для общего применения как-то не очень...

Ну тут особой проблемы нет, так как работа идет через сервер приложений. То есть предполагается, что security на его уровне обеспечивается. Хотя да, в общем случае наверное не правильно.

Тут на самом деле другая проблема, не понятно какие транзакции приоритетные, а какие нет. То есть в идеале хотелось бы, чтобы просто более старые транзакции были приоритетнее (хотя конечно в будущем возможно и имеет смысл для отдельных пользователей перегружать приоритет). Поэтому пока сделали так: перед каждым DML берется время с начала транзакции, логарифмируется по основание 2 (то есть берутся только 1, 2, 4, 8 и т.п. секунд, делается это чтобы ограничить линейно количество установки deadlock_timeout, мало ли какие там оверхеды), и соответственно когда новый порог достигнут устанавливается новый deadlock_timeout (соотвественно 1,2,4, 8 и т.п. с).

Главный вопрос как будет постгрес реагировать на изменение deadlock_timeout походу транзакции. Во всяком случае по исходникам это не очевидно. Но сегодня-завтра это уйдет в продакшн и будем наблюдать :)

PgSQLanonymous2Nitro_JunkieНу тут особой проблемы нет, так как работа идет через сервер приложений. То есть предполагается, что security на его уровне обеспечивается. Хотя да, в общем случае наверное не правильно.

Я в эту тему в основном из-за этого влез, извините...

Nitro_JunkieТут на самом деле другая проблема, не понятно какие транзакции приоритетные, а какие нет. То есть в идеале хотелось бы, чтобы просто более старые транзакции были приоритетнее (хотя конечно в будущем возможно и имеет смысл для отдельных пользователей перегружать приоритет). Поэтому пока сделали так: перед каждым DML берется время с начала транзакции, логарифмируется по основание 2 (то есть берутся только 1, 2, 4, 8 и т.п. секунд, делается это чтобы ограничить линейно количество установки deadlock_timeout, мало ли какие там оверхеды), и соответственно когда новый порог достигнут устанавливается новый deadlock_timeout (соотвественно 1,2,4, 8 и т.п. с).

Главный вопрос как будет постгрес реагировать на изменение deadlock_timeout походу транзакции. Во всяком случае по исходникам это не очевидно. Но сегодня-завтра это уйдет в продакшн и будем наблюдать :)
А по Вашему вопросу: по идее, deadlock_timeout Вам совсем не поможет, просто будет так:
1. Давно выполняющаяся транзакция A накладывает какие-то locks.
2. Тут приходит транзакция B с коротким deadlock_timeout, накладывает какие-то locks, и блокируется на каком-то lock, ранее наложенном A.
3. У B истекает deadlock_timeout, она проверяет DEADLOCK-и (а их нет) и продолжает ждать (вечно).
4. A пытается наложить lock на какой-то из ресурсов, захваченных B, блокируется, выжидает свой deadlock_timeout, откатывается.

Хм... Судя по исходникам так и есть :(

ЗЫ: Одно радует, что хоть для MS SQL такой механизм по идее должен работать.

Nitro_Junkie,

Хотя если к времени старта транзакции, добавлять время предыдущих попыток (с коэффициентом, например 0,5), через какое то время транзакции выйдут из хронического deadlock'а (когда время предыдущих попыток превысит предполагаемое время выполнения A и B).