Уровни изоляции в Postgres

Уровни как лестница обещаний

Выбирая уровень изоляции, ты не настраиваешь скорость — ты выбираешь класс багов, которые принимаешь. Слишком низкий уровень — тихая порча данных; слишком высокий — пишешь retry-логику. Точное знание границы каждого уровня и отличает сеньора, который предотвращает инциденты, от того, кто потом их отлаживает.

Уровень изоляции — не ручка производительности; это контракт о том, какие аномалии позволено наблюдать конкурентным транзакциям. Postgres предлагает три рабочих уровня (он принимает READ UNCOMMITTED, но трактует его как READ COMMITTED — грязные чтения в Postgres невозможны никогда).

• READ COMMITTED (по умолчанию) — ты видишь только закоммиченные данные, но каждый оператор берёт свежий снимок в начале оператора. Так что внутри одной транзакции два SELECT одной строки могут вернуть разные значения, если другая транзакция закоммитила между ними. Предотвращает: грязные чтения. Допускает: non-repeatable read, фантомы, lost update, write skew.
• REPEATABLE READ — транзакция берёт один снимок на первом операторе и использует его всю транзакцию. Каждое чтение видит базу на тот момент. Предотвращает: грязные чтения, non-repeatable read и (в Postgres) фантомы. Допускает: write skew. Запись, конфликтующая с коммитом другой транзакции, падает с serialization error.
• SERIALIZABLE — ведёт себя так, будто каждая транзакция шла одна за другой в некотором последовательном порядке. Реализован через Serializable Snapshot Isolation (SSI): отслеживает read/write-зависимости и прерывает транзакцию, чей коммит создал бы несериализуемое расписание. Предотвращает: всё, включая write skew. Цена: больше serialization failure, которые ты обязан повторять.

Снимок на оператор против снимка на транзакцию

Самое важное различие двух распространённых уровней — когда берётся снимок.

-- READ COMMITTED: каждый оператор переснимает.
BEGIN;  -- уровень по умолчанию
SELECT qty FROM inventory WHERE sku = 'A';   -- видит 10
-- ... другая сессия коммитит qty = 3 здесь ...
SELECT qty FROM inventory WHERE sku = 'A';   -- теперь видит 3  (non-repeatable read)
COMMIT;

-- REPEATABLE READ: один снимок на всю транзакцию.
BEGIN ISOLATION LEVEL REPEATABLE READ;
SELECT qty FROM inventory WHERE sku = 'A';   -- видит 10
-- ... другая сессия коммитит qty = 3 здесь ...
SELECT qty FROM inventory WHERE sku = 'A';   -- всё ещё видит 10  (стабильное чтение)
COMMIT;

READ COMMITTED правилен для коротких OLTP-операторов, где нужны самые свежие закоммиченные данные. REPEATABLE READ правилен для отчёта или многооператорного чтения, которое должно быть внутренне согласованным — баланс, который не сдвигается под тобой посреди запроса.

Внутренности — как снимки, xmin/xmax и видимость работают на самом деле — это глава MVCC трека databases; здесь мы остаёмся на уровне SQL-контракта. Смотри databases/04-mvcc-isolation/03-hot-updates-and-isolation-levels для механизма версий строк и databases/04-mvcc-isolation/06-ssi-and-production-tuning про то, как SSI отслеживает конфликты.

Write skew и почему его ловит только SERIALIZABLE

Write skew — аномалия, удивляющая сеньоров. Две транзакции читают пересекающийся набор строк, каждая проверяет инвариант, который сейчас держится, затем каждая пишет другую строку. Ни одна запись не конфликтует с другой (разные строки), так что проверка «первый-обновивший-выигрывает» REPEATABLE READ не срабатывает — но вместе они ломают инвариант.

-- Инвариант дежурства, защищённый через SERIALIZABLE:
BEGIN ISOLATION LEVEL SERIALIZABLE;
SELECT count(*) FROM doctors WHERE on_call = true;  -- должно остаться >= 1
-- приложение проверяет count >= 2 перед тем как разрешить это:
UPDATE doctors SET on_call = false WHERE id = 17;
COMMIT;   -- если конкурентная txn сломала сериализуемость, тут поднимется 40001

На SERIALIZABLE одна из двух конкурентных транзакций коммитится; другая получает ERROR: could not serialize access due to read/write dependencies among transactions (SQLSTATE 40001). Твоё приложение обязано ловить 40001 и повторять всю транзакцию. На повторе она перечитывает count = 1 и корректно отказывает. Без retry-логики SERIALIZABLE просто превращает тихую порчу данных в видимые ошибки, которые видят пользователи.