HOT-обновления и уровни изоляции

UPDATE обновляет неиндексированную колонку. Postgres пишет ноль новых индексных записей. WAL сокращается на 30–70%. Это называется HOT — и ты никогда этого не видишь, пока не узнаешь, куда смотреть.

HOT-обновления

Если UPDATE не трогает ни одну индексированную колонку и новый tuple влезает на ту же страницу, что и старый, Postgres выполняет heap-only tuple (HOT) обновление:

• Старый tuple получает флаг HEAP_HOT_UPDATED («иди по цепочке t_ctid»)
• Новый tuple получает флаг HEAP_ONLY_TUPLE («на меня не указывает ни один индекс»)
• Индекс продолжает указывать на исходный tuple, цепочка в heap доводит lookup до конца

Результат: ноль новых индексных записей. На UPDATE-нагруженных воркфлоу, где большинство колонок неиндексированы — это разница между удвоением WAL и его едва заметным ростом.

Условия HOT:

Fillfactor (ALTER TABLE foo SET (fillfactor = 85)) резервирует процент каждой heap-страницы под HOT-обновления. По умолчанию 100 — для UPDATE-нагруженных таблиц типично 70–90.

Мониторинг: pg_stat_all_tables.n_tup_hot_upd / n_tup_upd — HOT-доля. Выше 80% хорошо; ниже 50% — или слишком агрессивный fillfactor, или неправильный набор индексов.

Четыре уровня изоляции

Read Committed (по умолчанию) — каждый statement получает свежий snapshot. Два SELECT в одной транзакции могут увидеть разные данные.

Repeatable Read — единственный snapshot взят на первом statement. Postgres реализует RR как snapshot isolation — строже стандартного RR (phantom read запрещён), но write skew разрешён.

Serializable (с 9.1) — добавляет SSI поверх RR. Postgres отслеживает зависимости read–write и откатывает транзакции с SQLSTATE 40001, чей порядок коммита не соответствует ни одному серийному расписанию.

Write skew: аномалия, которую ловит только Serializable

Что должно делать приложение

Под Read Committed приложение само отвечает за предотвращение lost update:

• SELECT ... FOR UPDATE (пессимистичная блокировка строки)
• UPDATE ... WHERE version = ? с оптимистичной конкуренцией
• INSERT ... ON CONFLICT ... DO UPDATE для upsert

Под Repeatable Read и Serializable база поднимает SQLSTATE 40001 при конфликте. Единственный корректный ответ — повторить всю транзакцию.

Когда выбирать какой уровень

Read Committed — дефолт по причине: на 90% бизнес-логики даёт ожидаемую семантику и максимальный throughput, потому что snapshot перевычисляется на каждом statement.

Repeatable Read — когда логика опирается на стабильность набора строк между несколькими SELECT (например, отчёт суммирует поля, которые потом сверяет с агрегированной версией).

Serializable — когда у бизнес-логики есть инвариант, который сохраняется только при отсутствии write skew: на стороне финтеха «хотя бы один счёт остаётся включённым», в медицине «хотя бы один врач остаётся on-call», в инвентаре «никакая позиция не получает больше резервов, чем имеет на складе». Serializable не магия — он добавляет до 5x cost и предполагает готовность к ретраям.

Прикладные паттерны под Read Committed

SELECT ... FOR UPDATE на горячих строках — самый предсказуемый способ избежать lost update: блокировка эксклюзивная, держится до конца транзакции. Порядок взятия должен быть детерминистическим (например, по ascending id) во избежание deadlock.

Оптимистичная конкуренция через колонку version (или updated_at): SELECT читает версию, UPDATE проверяет её в WHERE и атомарно увеличивает; если строка не вернулась — повтор. Hibernate @Version, Sequelize versionAttribute, ActiveRecord optimistic_locking.

INSERT ... ON CONFLICT ... DO UPDATE (upsert) — атомарно решает гонку вставка-vs-обновление без явных блокировок, но требует уникального constraint.

Числа