Режим отказа очереди блокировок: почему мгновенный DDL может заморозить базу

Команда запускает ALTER TABLE users ADD COLUMN status TEXT DEFAULT 'active' в 14:00. На PG 16 этот запрос занимает 8 мс. Тем не менее таблица users недоступна 90 секунд, connection pool исчерпан, и сайт возвращает 503. Сама миграция была мгновенной. Что же произошло?

Матрица блокировок Postgres

Каждая операция с таблицей берёт блокировку. Существует восемь режимов блокировки от слабейшего к сильнейшему:

ACCESS SHARE → ROW SHARE → ROW EXCLUSIVE → SHARE UPDATE EXCLUSIVE → SHARE → SHARE ROW EXCLUSIVE → EXCLUSIVE → ACCESS EXCLUSIVE

Ключевые факты:

• SELECT берёт ACCESS SHARE (слабейший).
• Большинство DDL (ALTER TABLE, DROP TABLE, TRUNCATE) берёт ACCESS EXCLUSIVE (сильнейший — конфликтует со всем).
• CREATE INDEX CONCURRENTLY и VALIDATE CONSTRAINT берут SHARE UPDATE EXCLUSIVE — не блокируют обычный DML.

Матрица блокировок определяет, что может выполняться параллельно. ACCESS EXCLUSIVE конфликтует с каждым другим режимом блокировки, включая ACCESS SHARE. Это означает: любой DDL с ACCESS EXCLUSIVE должен ждать завершения всех текущих читателей — и блокирует всех новых читателей, пока ждёт.

FIFO-очередь блокировок — реальный режим отказа

Postgres выдаёт блокировки в порядке поступления (FIFO для объекта). Это создаёт классический инцидент с миграцией:

Критическое понимание: новые SELECT встают в очередь после ожидающего ALTER, потому что выдача им блокировок не по порядку лишила бы ALTER шанса когда-либо дождаться своей очереди. Запрос ALTER на ACCESS EXCLUSIVE уже в очереди; менеджер блокировок отказывается выдавать более лёгкие блокировки поздним прибывшим, конфликтующим с ним. Таблица заморожена для всех новых запросов на полные 60 секунд медленного SELECT — даже несмотря на то, что сама миграция выполняется за 8 мс.

Решение: SET lock_timeout

-- В начале каждой сессии миграции:
SET lock_timeout = '2s';
SET statement_timeout = '30s';

С lock_timeout = '2s':

• Миграция ждёт блокировку не более 2 секунд.
• Если блокировка не получена, миграция чисто завершается с ошибкой и освобождает своё место в очереди.
• Новые SELECT немедленно получают свои более лёгкие блокировки — таблица разморожена.
• Инструмент миграции повторяет попытку с экспоненциальным откатом (1с, 2с, 4с, 8с…).
• В конечном счёте медленный SELECT завершается или открывается тихое окно, и миграция успешно выполняется.

Без lock_timeout (умолчание Postgres = 0 — ждать вечно): один медленный запрос может заморозить таблицу на всё своё время выполнения.