Список ниже показывает доступные режимы блокировки и контексты, в которых они автоматически используются Tantor SE-1C. Также можно явно получить любую из этих блокировок с помощью команды LOCK. Помните, что все эти режимы блокировки являются блокировками на уровне таблицы, даже если в названии есть слово “row”; названия режимов блокировки исторические. В некоторой степени названия отражают типичное использование каждого режима блокировки, но семантика одинакова. Единственное реальное отличие между режимами блокировки - это набор режимов блокировки, с которыми каждый конфликтует (см. Таблица 13.2). Две транзакции не могут удерживать блокировки конфликтующих режимов на одной и той же таблице одновременно. (Однако транзакция никогда не конфликтует сама с собой. Например, она может получить блокировку ACCESS EXCLUSIVE и позже получить блокировку ACCESS SHARE на той же таблице). Неконфликтующие режимы блокировки могут быть удерживаемыми одновременно множеством транзакций. Обратите внимание, что некоторые режимы блокировки конфликтуют сами с собой (например, блокировка ACCESS EXCLUSIVE не может быть удерживаемой более чем одной транзакцией одновременно), в то время как другие не конфликтуют сами с собой (например, блокировка ACCESS SHARE может быть удерживаемой несколькими транзакциями).

После получения блокировки она обычно удерживается до конца транзакции. Но если блокировка получена после установки точки сохранения, то блокировка освобождается немедленно, если точка сохранения откатывается. Это соответствует принципу, что ROLLBACK отменяет все эффекты команд, выполненных после точки сохранения. То же самое относится к блокировкам, полученным внутри блока исключения PL/pgSQL: при выходе из блока из-за ошибки освобождаются блокировки, полученные внутри него.

В дополнение к блокировкам на уровне таблицы, существуют блокировки на уровне строк, которые автоматически используются Tantor SE-1C в следующих контекстах. См. Таблица 13.3 для полной таблицы конфликтов блокировок на уровне строк. Обратите внимание, что транзакция может удерживать конфликтующие блокировки на одной и той же строке, даже в разных подтранзакциях; но помимо этого, две транзакции никогда не могут удерживать конфликтующие блокировки на одной и той же строке. Блокировки на уровне строк не влияют на запросы данных; они блокируют только писателей и блокировщиков для одной и той же строки. Блокировки на уровне строк освобождаются при завершении транзакции или во время отката точки сохранения, так же как и блокировки на уровне таблицы.

Tantor SE-1C не сохраняет никакую информацию о измененных строках в памяти, поэтому нет ограничений на количество заблокированных строк одновременно. Однако блокировка строки может вызвать запись на диск, например, SELECT FOR UPDATE изменяет выбранные строки для их пометки как заблокированные, и поэтому приводит к записи на диск.

В дополнение к блокировкам таблицы и строки, на уровне страниц используются общие/исключительные блокировки для контроля доступа на чтение/запись к страницам таблицы в общем буфере. Эти блокировки снимаются немедленно после извлечения или обновления строки. Разработчикам приложений обычно не нужно беспокоиться о блокировках на уровне страниц, но они упоминаются здесь для полноты.

Использование явной блокировки может увеличить вероятность возникновения взаимоблокировок, когда две (или более) транзакции удерживают блокировки, которые другая транзакция хочет получить. Например, если транзакция 1 получает исключающую блокировку на таблицу A, а затем пытается получить исключающую блокировку на таблицу B, в то время как транзакция 2 уже удерживает исключающую блокировку на таблицу B и теперь хочет получить исключающую блокировку на таблицу A, то ни одна из них не может продолжить выполнение. Tantor SE-1C автоматически обнаруживает ситуации взаимоблокировки и разрешает их, прерывая одну из вовлеченных транзакций и позволяя другим завершиться. (Точно определить, какая транзакция будет прервана, сложно предсказать и на это нельзя полагаться).

Обратите внимание, что дедлоки могут возникать также в результате блокировки на уровне строк (и, следовательно, они могут возникать даже если явная блокировка не используется). Рассмотрим случай, когда две параллельные транзакции изменяют таблицу. Первая транзакция выполняет:

UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 11111;

Включается блокировка на уровне строки для строки с указанным номером счета. Затем вторая транзакция выполняется:

UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 22222;
UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 11111;

Первый оператор UPDATE успешно получает блокировку на уровне строки для указанной строки, поэтому он успешно обновляет эту строку. Однако второй оператор UPDATE обнаруживает, что строка, которую он пытается обновить, уже заблокирована, поэтому он ожидает завершения транзакции, которая получила блокировку. Транзакция два теперь ожидает завершения транзакции один, прежде чем продолжить выполнение. Теперь транзакция один выполняется:

UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 22222;

Транзакция один пытается получить блокировку на уровне строки для указанной строки, но не может: транзакция два уже удерживает такую блокировку. Поэтому она ожидает завершения транзакции два. Таким образом, транзакция один блокируется на транзакции два, а транзакция два блокируется на транзакции один: возникает ситуация взаимной блокировки. Tantor SE-1C обнаружит эту ситуацию и прервет одну из транзакций.

Лучшая защита от дедлоков, как правило, заключается в их предотвращении путем обеспечения того, чтобы все приложения, использующие базу данных, получали блокировки на нескольких объектах в одном и том же порядке. В приведенном выше примере, если бы обе транзакции обновляли строки в одном и том же порядке, дедлок не произошел бы. Также следует обеспечить, чтобы первая блокировка, полученная на объекте в транзакции, была наиболее ограничивающим режимом, который будет необходим для этого объекта. Если невозможно проверить это заранее, то дедлоки могут быть обработаны на лету путем повторного выполнения транзакций, которые прерываются из-за дедлоков.

Пока не будет обнаружена ситуация блокировки, транзакция, запрашивающая блокировку на уровне таблицы или строк, будет бесконечно ждать, пока конфликтующие блокировки не будут освобождены. Это означает, что длительное открытие транзакций (например, во время ожидания пользовательского ввода) является плохой идеей для приложений.

Tantor SE-1C предоставляет средство для создания блокировок, которые имеют определенное приложением значение. Они называются рекомендательными блокировками, потому что система не обязывает их использовать - это зависит от приложения, как их использовать правильно. Рекомендательные блокировки могут быть полезны для стратегий блокировки, которые неудобно сочетаются с моделью MVCC. Например, обычное использование рекомендательных блокировок - эмуляция пессимистических стратегий блокировки, типичных для так называемых систем управления данными “плоского файла”. Хотя флаг, хранящийся в таблице, может использоваться для той же цели, рекомендательные блокировки работают быстрее, избегают раздутия таблицы и автоматически очищаются сервером в конце сессии.

Есть два способа получить рекомендательную блокировку в Tantor SE-1C: на уровне сессии или на уровне транзакции. Полученная на уровне сессии рекомендательная блокировка сохраняется до явного освобождения или завершения сессии. В отличие от стандартных запросов на блокировку, запросы на рекомендательную блокировку на уровне сессии не учитывают семантику транзакции: блокировка, полученная во время транзакции, которая позже откатывается, все равно будет сохранена после отката, и, аналогично, разблокировка будет действительна даже если вызывающая транзакция завершится с ошибкой. Блокировка может быть получена несколько раз владеющим процессом; для каждого завершенного запроса на блокировку должен быть соответствующий запрос на разблокировку, прежде чем блокировка будет фактически освобождена. Запросы на блокировку на уровне транзакции, с другой стороны, ведут себя более похоже на обычные запросы на блокировку: они автоматически освобождаются в конце транзакции, и нет явной операции разблокировки. Такое поведение часто более удобно, чем поведение на уровне сессии, для краткосрочного использования рекомендательной блокировки. Запросы на блокировку на уровне сессии и на уровне транзакции для одного и того же идентификатора рекомендательной блокировки будут блокировать друг друга ожидаемым образом. Если сессия уже удерживает определенную рекомендательную блокировку, дополнительные запросы от нее всегда будут успешными, даже если другие сессии ожидают блокировки; это утверждение верно независимо от того, является ли существующая блокировка на уровне сессии или на уровне транзакции.

Как и все блокировки в Tantor SE-1C, полный список рекомендательных блокировок, в настоящее время удерживаемых любой сессией, можно найти в системном представлении pg_locks.

Все рекомендательные блокировки и обычные блокировки хранятся в общем пуле общей памяти, размер которого определяется переменными конфигурации max_locks_per_transaction и max_connections. Необходимо быть осторожным, чтобы не исчерпать эту память, иначе сервер не сможет предоставить никаких блокировок. Это накладывает верхний предел на количество рекомендательных блокировок, которые может предоставить сервер, обычно в диапазоне от десятков до сотен тысяч, в зависимости от конфигурации сервера.

В некоторых случаях при использовании методов рекомендательной блокировки, особенно в запросах, включающих явное упорядочивание и ограничения LIMIT, необходимо контролировать получаемые блокировки из-за порядка вычисления SQL-выражений. Например:

SELECT pg_advisory_lock(id) FROM foo WHERE id = 12345; -- ok
SELECT pg_advisory_lock(id) FROM foo WHERE id > 12345 LIMIT 100; -- danger!
SELECT pg_advisory_lock(q.id) FROM
(
  SELECT id FROM foo WHERE id > 12345 LIMIT 100
) q; -- ok

В приведенных выше запросах вторая форма опасна, потому что LIMIT не гарантируется применяться перед выполнением функции блокировки. Это может привести к получению некоторых блокировок, которые приложение не ожидало, и, следовательно, не смогло бы их освободить (пока не завершится сессия). С точки зрения приложения такие блокировки будут висячими, хотя они все еще будут видны в pg_locks.

Все функции, предоставляемые для работы с рекомендательными блокировками, описаны в Раздел 9.27.10.