Поймай каскад блокировок от idle-in-transaction

Шаги

1. 01

   Сессия A держит таблицу и забывает закоммитить

   Открой psql во вкладке psql-a и начни транзакцию, не закрывая её:

   sqlcopy

   BEGIN;

   SELECT count(*) FROM flights;

   Приглашение стало lab=*# - звёздочка значит «транзакция открыта». Запрос отработал, но ACCESS SHARE на flights держится. Не вводи COMMIT.

   подсказка

   Звёздочка в приглашении psql = открытая транзакция. Это и есть idle in transaction.

   ✓ A висит в idle in transaction и держит ACCESS SHARE на flights.

2. 02

   Сессия B выкатывает миграцию

   Перейди во вкладку psql-b, запусти psql и выполни:

   sqlcopy

   ALTER TABLE flights ADD COLUMN gate text;

   Команда не вернёт приглашение - она повисла. ALTER TABLE хочет ACCESS EXCLUSIVE, который конфликтует с ACCESS SHARE сессии A. Предскажи: сколько невыданных (granted = f) блокировок по flights сейчас в pg_locks?

   подсказка

   Невыданная блокировка - это строка pg_locks с granted = f. Её ждёт B.

   ✓ B встал в очередь за ACCESS EXCLUSIVE - есть невыданная блокировка.

3. 03

   Сессия C - обычный SELECT - тоже виснет

   Вкладка psql-c, запусти psql, потом:

   sqlcopy

   SELECT * FROM flights LIMIT 1;

   C совместима с A (два читателя), но впереди в очереди стоит B с ACCESS EXCLUSIVE, а очередь честная - перепрыгнуть ждущего нельзя. Поэтому C тоже виснет. Предскажи, сколько сессий теперь ждут блокировку (wait_event_type = 'Lock').

   подсказка

   Ждут и B, и C. wait_event_type='Lock' - именно про ожидание тяжёлой блокировки.

   ✓ Две сессии в очереди. Один SELECT остановил всю таблицу.

4. 04

   Найди корень каскада по PID

   Во вкладке psql-ops запусти psql и найди, кто кого блокирует:

   sqlcopy

   SELECT w.pid AS waiting, b.pid AS blocking, b.state, b.query

   FROM pg_stat_activity w

   JOIN LATERAL unnest(pg_blocking_pids(w.pid)) AS bp(pid) ON true

   JOIN pg_stat_activity b ON b.pid = bp.pid

   WHERE cardinality(pg_blocking_pids(w.pid)) > 0;

   Цепочка ведёт к сессии A в состоянии idle in transaction - это корень. Запиши её PID (колонка blocking с state = idle in transaction).

   подсказка

   pg_blocking_pids(pid) возвращает массив тех, кто мешает данному процессу.

   ✓ Видно две заблокированные сессии, корень - idle-in-transaction A.

5. 05

   Сними блокировщика и проверь, что завал ушёл

   Корень в idle in transaction, значит pg_cancel_backend не поможет (нет активного запроса). Нужен pg_terminate_backend. Во вкладке psql-ops найди PID сессии A и закрой её:

   sqlcopy

   -- подставь PID сессии A из прошлого шага

   SELECT pg_terminate_backend(<pid_A>);

   Как только A закрыта, её ACCESS SHARE спадает: B применяет миграцию, C получает результат. Проверим по факту - в flights появилась колонка gate.

   подсказка

   pg_terminate_backend закрывает соединение целиком: транзакция откатывается, блокировки спадают.

   ✓ Миграция прошла, колонка gate на месте. Каскад разобран.