03_deadlocks.sql

-- Тема: дедлоки (см. theory/software-engineering.md → «Дедлоки»).
--
-- Задача — руками воспроизвести дедлок, а потом починить его.
-- Понадобятся ДВЕ сессии psql (два терминала), назовём их T1 и T2.
-- Таблицу берём из 01_indexing.sql (employees) — достаточно пары строк.

-- Подготовка (в любой сессии):
--   UPDATE employees SET score = 100 WHERE id IN (1, 2);


-- ── Часть 1. Воспроизвести дедлок ────────────────────────────────────────────
-- Выполняй по шагам, ЧЕРЕДУЯ сессии в указанном порядке.
--
-- T1:  BEGIN;
--      UPDATE employees SET score = score + 1 WHERE id = 1;   -- держит lock на строке 1
--
-- T2:  BEGIN;
--      UPDATE employees SET score = score + 1 WHERE id = 2;   -- держит lock на строке 2
--
-- T1:  UPDATE employees SET score = score + 1 WHERE id = 2;   -- ждёт lock T2
--
-- T2:  UPDATE employees SET score = score + 1 WHERE id = 1;   -- ждёт lock T1  -> DEADLOCK
--
-- Одну из транзакций Postgres убьёт:
--   ERROR: deadlock detected
-- Разберись по сообщению: какая транзакция стала жертвой и почему (lock graph).


-- ── Часть 2. Починить ────────────────────────────────────────────────────────
-- ЗАДАЧА (todo): перепиши сценарий так, чтобы дедлока НЕ было.
-- Подсказки из теории:
--   * единый порядок захвата ресурсов (обе транзакции трогают строки в одном
--     и том же порядке id: сначала 1, потом 2);
--   * короткие транзакции;
--   * при необходимости — SELECT ... FOR UPDATE в нужном порядке и/или retry.
--
-- Впиши сюда исправленную последовательность шагов для T1 и T2:

-- T1: BEGIN;
--     -- todo
--     COMMIT;

-- T2: BEGIN;
--     -- todo
--     COMMIT;


-- ── Часть 3. Вопрос на подумать ──────────────────────────────────────────────
-- Почему deadlock detection не заменяет правильный порядок захвата,
-- и чем короткие транзакции + retry помогают под нагрузкой?