MVCC: как Postgres раздаёт согласованные снимки

Пятиминутный аналитический запрос и тысячи транзакций оформления заказов идут параллельно. Ни один не блокирует другой. Как Postgres это делает?

Что делает MVCC

MVCC хранит историю каждой строки так, чтобы каждая транзакция видела стабильную картину базы, не блокируя строки, которые трогают другие.

Без MVCC пятиминутный аналитический запрос замораживал бы каждый входящий заказ, а твой дашборд либо врал бы про итоги, либо блокировал кнопку оформления.

Метафора

Представь шумную библиотеку, где у каждой книги много копий, помеченных датой, когда их взяли с полки. Когда Свен просит «каталог на момент, когда я начал читать», библиотекарь выдаёт ему помеченную копию, замороженную на ту минуту — даже если Отто в это же время за стойкой сшивает новое издание.

Свен спокойно читает свою копию. Отто добавляет новое издание. Никто не ждёт никого; оба смотрят на разные датированные копии одной полки.

Позже уборщик проходит и выкидывает копии, которые никто больше не читает. Эта уборка — то, что Postgres называет VACUUM. Уборщик выбрасывает копию только тогда, когда ни один читатель её больше не держит.

Свен и Отто

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

Без MVCC отчёт либо блокирует orders (заморозив оформление), либо видит недописанные обновления. С MVCC Свен получает snapshot на момент старта отчёта; новые заказы идут в свежие версии, невидимые Свену. Отчёт заканчивается, оформление не зависает.

Одна ловушка, которую MVCC не решает

Две вкладки редактируют один профиль. Вкладка A загрузила, ты печатаешь. B загрузила, изменила одно поле, сохранила. Сохраняешь A — правка B молча исчезла. Это lost update.

MVCC сам по себе не лечит — попроси базу (SELECT FOR UPDATE или строже уровень изоляции).

Как это выглядит на диске