Архитектура

Блокировки

12

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

© Postgres Professional, 2020 год.

Авторы: Егор Рогов, Павел Лузанов

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

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

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

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

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

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

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

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

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

Блокировки используются, чтобы упорядочить конкурентный доступ

к разделяемым ресурсам.

Под конкурентным доступом понимается одновременный доступ

нескольких процессов. Сами процессы могут выполняться как

параллельно (если позволяет аппаратура), так и последовательно

в режиме разделения времени.

больше не нужен процессу, он освобождает блокировку, чтобы

ресурсом могли воспользоваться другие процессы.

Захват блокировки возможен не всегда: ресурс может оказаться уже

занятым кем-то другим в несовместимом режиме. В простом случае

используют два режима: исключительный (несовместим ни с чем) и

разделяемый (совместим сам с собой). Но их может быть и больше,

в этом случае совместимость определяется матрицей.

Если ресурс занят, процесс должен встать в очередь ожидания. Это,

конечно, уменьшает производительность системы. Поэтому для

создания высокоэффективных приложений важно понимать механизм

Из всего многообразия блокировок на уровне объектов мы рассмотрим

только блокировки номера транзакции и блокировки отношений.

Еще один вид блокировок того же типа – рекомендательные

блокировки – рассматривается в курсе DEV1.

Рассмотрение блокировок на уровне объектов («обычные», «тяжелые»

блокировки) мы начнем с блокировок номера транзакции.

Блокировки объектов располагаются в общей памяти сервера, поэтому

их общее количество ограничено. Все такие блокировки можно

посмотреть в представлении pg_locks: они устроены одинаково и

отличаются только типом ресурса и режимами блокирования.

Блокировки номера транзакции отображаются в pg_locks с типами

ресурса Transactionid и Virtualxid.

Это сделано для оптимизации. Виртуальный номер никак не

учитывается в правилах видимости. Кроме того, виртуальный номер не

обязан быть полностью уникальным (аналогично номеру процесса

в Unix) и его можно выдать быстро, без обращения к общей памяти.

Настоящий номер присваивается в тот момент, когда транзакция

Каждая транзакция всегда сама удерживает исключительную

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

когда блокировка освободится, а произойдет это при завершении

транзакции.

Второй важный случай блокировок объектов — блокировки отношений

(таблиц, индексов, последовательностей и т. п.). Такие блокировки

имеют тип Relation в pg_locks.

Для них определено целых 8 различных режимов, которые показаны на

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

режимы. Матрица совместимости здесь не показана из-за ее большого

размера, но она приведена в документации:

Такое количество режимов существуют для того, чтобы позволить

выполнять одновременно как можно большее количество команд,

Самый слабый режим — Access Share, он захватывается командой

SELECT и совместим с любым режимом, кроме самого сильного —

Access Exclusive. Это означает, что запрос не мешает ни другим

запросам, ни изменению данных в таблице, ни чему-либо другому, но не

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

данные.

Другой пример: режим Share (как и другие более сильные режимы) не

совместимы с изменением данных в таблице. Например, команда

CREATE INDEX заблокирует команды INSERT, UPDATE и DELETE

(и наоборот). Поэтому есть команда CREATE INDEX CONCURRENTLY,

использующая режим Share Update Exclusive, который совместим

SELECT

Блокировки объектов предоставляют «честную» очередь ожидания. Это

означает, что операции с несовместимыми режимами выстраиваются

в очередь и вне очереди никто не проходит.

Например, на рисунке выполняется команда UPDATE. Операция

CREATE INDEX встает в очередь, поскольку использует несовместимый

режим. Если следом придет команда VACUUM FULL (использующая

самый сильный режим, не совместимый ни с чем), она встанет

в очередь за CREATE INDEX.

захватить блокировку, уже занятую в несовместимом режиме.

После того, как первая транзакция завершается, блокировку

захватывает следующая транзакция, стоящая в очереди.

xmaxxmin данные

100 . . .101

T

T

Транзакция 102 захватила блокировку tuple для первой версии строки

(п. 1), но затем (п. 2) обнаружила, что версия строки уже заблокирована

транзакцией 101.

Теперь ей надо дождаться, пока строка освободится, но как это

сделать? Для этого используется своего рода трюк. Как мы уже

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

своего номера. Поскольку транзакция 102 фактически должна

дождаться завершения транзакции 101 (ведь блокировка строки

освобождается только при завершении транзакции), она запрашивает

блокировку номера 101.

Обратите внимание, что блокировка tuple при этом остается, так как

снимается только в п. 3, до которого дело еще не дошло.

xmaxxmin данные

100 . . .101

T

T

T

Если появляются другие транзакции, конфликтующие с текущей

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

типа tuple для этой строки — и выстраиваются в очередь.

В нашем примере, поскольку блокировка tuple уже удерживается

транзакцией 102, транзакции 103, 104 ждут освобождения этой

блокировки.

101 . . .

xmaxxmin данные

100 . . .101

102

T

T

T

Получается двухуровневая очередь. Одна из транзакций (102

в примере) — «крайняя», и за ней — все остальные.

Когда транзакция 101 завершится, именно транзакция 102 получит

возможность первой записать свой номер в поле xmax, после чего она

освободит блокировку tuple.

Когда транзакция 102 освободит версию строки, среди ожидающих

транзакций возникает гонка за право захватить блокировку.

Если бы не двухуровневая схема блокирования, то такая гонка со

случайным победителем возникала бы всегда. Это могло бы приводить

к ситуации вечного ожидания «невезучей» транзакции. Наличие

блокировки типа tuple решает — хотя бы отчасти — эту проблему.

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

изменения одной и той же строки. В этом случае возникает «горячая

точка», которая на высоких нагрузках может привести к снижению

производительности.

2. Рекомендательные блокировки рассматриваются в курсе DEV1.