Лёгкие и предикатные блокировки

У PostgreSQL не один механизм блокировок, а три, под разные задачи и разное время жизни.

Тяжёлые мы уже знаем: они про логику данных, держатся долго, у них есть очередь и детектор deadlock. Лёгкие и spinlock - про целостность внутренних структур самого сервера: буферный кеш, буферы WAL, таблицы хешей в памяти. Они короткие и не имеют отношения к твоим транзакциям как к данным - только к тому, чтобы два бэкенда не испортили общую структуру, трогая её одновременно.

LWLock охраняет конкретную структуру в разделяемой памяти на время, пока с ней работают. Пример: чтобы прочитать страницу из буферного кеша, бэкенд берёт LWLock на нужный буфер, копирует, отпускает. Чтобы дописать запись в буфер WAL - берёт LWLock на вставку в WAL.

У LWLock два режима: разделяемый (несколько читателей) и исключительный (один писатель), как у тяжёлых SHARE/EXCLUSIVE. Но есть три принципиальных отличия от тяжёлых:

• они держатся не до конца транзакции, а до конца короткой операции - микросекунды;
• у них нет обнаружения взаимоблокировок: код ядра берёт LWLock в строго фиксированном порядке, поэтому цикл невозможен по построению;
• их нет в pg_locks - там только тяжёлые. LWLock проявляется как ожидание с wait_event_type = 'LWLock'.

Имена LWLock говорят, за что идёт борьба: WALInsert - вставка в WAL, BufferContent - содержимое буфера, LockManager - сама таблица тяжёлых блокировок. Если под нагрузкой бэкенды массово ждут WALInsert, узкое место - запись журнала, а не диск с данными.

Иногда нужно защитить буквально пару инструкций - например, увеличить счётчик в общей структуре. Заводить ради этого LWLock дорого: сама постановка в очередь LWLock тяжелее, чем защищаемая работа.

Для таких случаев есть spinlock. Он не усыпляет процесс: если замок занят, бэкенд крутится в коротком цикле (busy-wait), снова и снова проверяя, не освободился ли он. Это разумно, только если замок держат считанные такты - дольше крутиться было бы расточительно.

Spinlock нигде не видно: у него нет ни имени, ни записи, ни wait_event. Это сознательно - любой учёт стоил бы больше самой защищаемой операции. Для тебя как пользователя spinlock - деталь реализации; знать о нём полезно лишь чтобы понимать, что не каждая синхронизация внутри сервера отражается в статистике.

Раз LWLock и ожидания тяжёлых блокировок не сводятся в одну таблицу, нужен общий язык «на чём именно сейчас ждёт процесс». Это и есть wait events. Каждый бэкенд в pg_stat_activity показывает две колонки:

SELECT pid, state, wait_event_type, wait_event, query

FROM pg_stat_activity

WHERE state != 'idle';

wait_event_type - категория ожидания, wait_event - конкретное событие. Основные категории:

Если wait_event_type пустой, процесс не ждёт - он работает на процессоре. Это тоже информация: упёрлись в CPU, а не в блокировки или диск.

Один снимок pg_stat_activity показывает ожидания в момент запроса - этого мало. Узкое место ищут семплированием: снимают wait_event много раз подряд и смотрят, какое событие встречается чаще всего. Это профилировщик для бедных, встроенный в сервер.

-- грубое семплирование: что чаще всего под нагрузкой

SELECT wait_event_type, wait_event, count(*)

FROM pg_stat_activity

WHERE state = 'active'

GROUP BY 1, 2

ORDER BY count(*) DESC;

Прогнав такой запрос десятки раз во время нагрузки, получаешь распределение: если 80% выборок показывают Lock, проблема в конкуренции за строки; если IO:DataFileRead - не хватает кеша и бьём по диску; если событий нет вовсе - всё упёрлось в процессор. В продакшене это семплирование автоматизируют расширениями, но принцип ровно тот же.

Последний вид - предикатные блокировки, и они самые контринтуитивные. Их использует уровень изоляции Serializable в реализации SSI (Serializable Snapshot Isolation). Слово «блокировка» здесь почти обманывает: предикатная блокировка никого не заставляет ждать.

Идея такая. На Serializable PostgreSQL должен гарантировать, что результат параллельных транзакций совпадёт с каким-нибудь последовательным их выполнением. Для этого ему мало версий строк - нужно знать, какие данные транзакция читала, чтобы поймать ситуацию, когда другая транзакция изменила ровно то, на чём первая строила решение.

Поэтому при чтении на Serializable транзакция оставляет предикатную блокировку (SIReadLock) на прочитанных строках, страницах или таблице - метку «я это читала». Эти метки никого не тормозят. Но если другая транзакция пишет туда, куда стоит чужой SIReadLock, и вместе они образуют опасный шаблон зависимостей, одна из них при коммите получит ошибку сериализации (SQLSTATE 40001). Проверять SSI помогает lightweight-predicate-locks.

В отличие от LWLock, предикатные блокировки видны в pg_locks - с режимом SIReadLock:

BEGIN ISOLATION LEVEL SERIALIZABLE;

SELECT count(*) FROM flights WHERE departure = 'SVO';

SELECT locktype, relation::regclass, mode

FROM pg_locks WHERE mode = 'SIReadLock';

Гранулярность у них переменная: сначала PostgreSQL метит отдельные кортежи, но если их слишком много, огрубляет до страницы, а затем до всей таблицы - чтобы не утонуть в учёте. Огрубление повышает шанс ложного срабатывания (ошибка сериализации там, где реального конфликта не было), зато ограничивает память. Это компромисс между точностью и стоимостью, типичный для Serializable: на нём приложение обязано быть готовым повторять транзакцию при 40001, как при deadlock.