Архитектура

Изоляция и многоверсионность

13

Авторские права

© Postgres Professional, 2015–2022

Авторы: Егор Рогов, Павел Лузанов, Илья Баштанов

Обратная связь

Отзывы, замечания и предложения направляйте по адресу:

Отказ от ответственности

Компания Postgres Professional не несет никакой ответственности за

любые повреждения и убытки, включая потерю дохода, нанесенные

прямым или непрямым, специальным или случайным использованием

материалов курса. Компания Postgres Professional не предоставляет

каких-либо гарантий на материалы курса. Материалы курса

предоставляются на основе принципа «как есть» и компания Postgres

выполняют изменения друг за другом). Самый интересный вариант —

как взаимодействуют пишущая и читающая транзакции.

Простых пути два. Такие транзакции могут блокировать друг друга —

но тогда страдает производительность. Либо же читающая транзакция

сразу видит изменения, сделанные пишущей транзакцией, даже если

они не зафиксированы (это называется «грязным чтением») — но это

очень плохо, ведь изменения могут быть отменены.

PostgreSQL идет сложным путем и использует многоверсионность —

хранит несколько версий одной и той же строки. При этом пишущая

транзакция работает со своей версией, а читающая видит свою.

выполнившей команду INSERT. Когда удаляется — версия помечается

номером транзакции, выполнившей DELETE (но физически не

удаляется). UPDATE состоит из двух операций DELETE и INSERT.

снимок

Транзакция, обращаясь к таблице, должна видеть только одну из

имеющихся версий каждой строки (или не видеть ни одной). Для этого

видны. Иными словами, от каждой строки в снимок попадает версия,

соответствующая моменту создания снимка.

- список активных транзакций на этот момент.

Список нужен для того, чтобы исключить из снимка изменения тех

транзакций, которые начались до создания снимка, но еще не были

зафиксированы.

Зная эти числа, мы всегда можем сказать, какая из версий строки будет

видна в снимке. Иногда это будет актуальная (самая последняя)

версия, как для строки 1 на иллюстрации. Иногда не самая последняя:

строка 2 удалена (и изменение уже зафиксировано), но транзакция

еще продолжает видеть эту строку, пока работает со своим снимком.

Это правильное поведение — оно дает согласованную картину данных

сильнее его влияние на производительность (с тех пор эти

представления несколько изменились).

Самый нестрогий уровень Read Uncommitted допускает грязные

чтения. Он не поддерживается PostgreSQL, поскольку не представляет

практической ценности и не дает выигрыша в производительности.

Уровень Read Committed является уровнем изоляции по умолчанию

в PostgreSQL. На этом уровне снимки данных строятся в начале

выполнения каждого оператора SQL. Таким образом, оператор

работает с неизменной и согласованной картиной данных, но два

одинаковых запроса, следующих один за другим, могут показать

разные данные.

транзакции видят одни и те же данные. Этот уровень удобен,

операторы так, как будто транзакция работает одна. Плата за

удобство — определенная доля транзакций завершается с ошибкой;

приложение должно уметь повторять такие транзакции.

транзакция будет ждать освобождения блокировки — если она

пытается менять строку, которая уже изменена другой, еще не

зафиксированной, транзакцией.

Блокировки также устанавливаются на более высоком уровне,

в частности на таблицах. Они нужны для того, чтобы никто не смог

удалить таблицу, пока другие транзакции читают из нее данные, или

чтобы запретить доступ к перестраиваемой таблице. Как правило,

такие блокировки не вызывают проблем, поскольку удаление или

перестроение таблиц — очень редкие операции.

также установить и дополнительные пользовательские блокировки;

транзакции требуются два бита.

служебных файлах в каталоге PGDATA/pg_xact, а работа с ними

происходит в общей памяти сервера, чтобы не приходилось постоянно

обращаться к диску.

При любом завершении транзакции (как успешном, так и неуспешном)

необходимо всего лишь установить соответствующие биты статуса. Как

фиксация, так и обрыв транзакций происходят одинаково быстро.

Если прерванная транзакция успела создать новые версии строк, эти

версии не уничтожаются (не происходит «физического» отката данных).