Deadlock'и

Анатомия deadlock’а

Когда видишь в продакшн-логах ERROR: deadlock detected, инстинкт — подкрутить deadlock_timeout или добавить retry и двигаться дальше. Сопротивляйся. Каждый deadlock указывает на инверсию порядка, которую однострочный фикс устраняет навсегда.

Deadlock’у нужен ровно один ингредиент: две транзакции, захватывающие одни блокировки в противоположном порядке. Каждая берёт первую блокировку, затем просит вторую — которую уже держит другая — и ни одна не отпустит, пока не получит то, на чём заблокирована. Это цикл в графе ожиданий, и никакое ожидание его не разрешит.

-- Транзакция 1                            -- Транзакция 2
BEGIN;                                     BEGIN;
UPDATE accounts SET balance = balance - 100
  WHERE id = 1;       -- блокирует строку 1
                                           UPDATE accounts SET balance = balance - 50
                                             WHERE id = 2;     -- блокирует строку 2
UPDATE accounts SET balance = balance + 100
  WHERE id = 2;       -- ЖДЁТ строку 2 (держит Tx2)
                                           UPDATE accounts SET balance = balance + 50
                                             WHERE id = 1;     -- ЖДЁТ строку 1 (держит Tx1)
-- теперь обе ждут друг друга вечно -> deadlock

Как Postgres его обнаруживает и разрешает

Postgres не проверяет deadlock на каждом ожидании блокировки — это было бы дорого. Вместо этого, когда транзакция блокируется на блокировке, она ждёт deadlock_timeout (по умолчанию 1 секунда) и только затем запускает детектор deadlock’ов, который обходит граф ожиданий в поисках цикла. Найдя его, он выбирает жертву и прерывает её:

ERROR:  deadlock detected
DETAIL:  Process 1234 waits for ShareLock on transaction 5678; blocked by process 4321.
         Process 4321 waits for ShareLock on transaction 8765; blocked by process 1234.
HINT:    See server log for query details.
SQLSTATE: 40P01

Транзакция жертвы откатывается целиком; выживший идёт дальше. deadlock_timeout в 1 секунду означает, что реальный deadlock стоит как минимум ~1с задержки до разрешения, так что частые deadlock’и — и запах корректности, и проблема задержки. Снижение timeout ускоряет обнаружение, но добавляет CPU на каждом обычном ожидании блокировки — не крути его, пока не починишь порядок.

Профилактика лучше обнаружения

Обнаружение — страховочная сетка, а не стратегия. Лекарство — консистентный порядок блокировок: если каждая транзакция, трогающая несколько строк, всегда блокирует их в одном глобальном порядке, цикл невозможен.

-- Перевод без deadlock: блокируем обе строки одним оператором, меньший id первым.
BEGIN;
SELECT id FROM accounts
WHERE id IN (:from_id, :to_id)
ORDER BY id           -- магия: детерминированный порядок, оба направления
FOR UPDATE;
UPDATE accounts SET balance = balance - :amt WHERE id = :from_id;
UPDATE accounts SET balance = balance + :amt WHERE id = :to_id;
COMMIT;

Поскольку transfer(1, 2) и transfer(2, 1) теперь оба блокируют id 1 раньше id 2, один полностью захватывает до старта другого — цикла нет. Остальные рычаги по приоритету: держи транзакции короткими (меньше времени с блокировками = меньше окно столкновений), трогай строки в стабильном порядке по всему приложению и лишь затем рассматривай NOWAIT, чтобы падать быстро, а не выжидать timeout.