Как работают блокировки в базе данных с разделяемыми/исключительными блокировками, когда оператор UPDATE выполняется в начале транзакции?

Как работают блокировки в базе данных с разделяемыми/исключительными блокировками, когда оператор UPDATE выполняется в начале транзакции? Предполагая Repeatable Read или выше, он получает общую блокировку на этапе чтения и поиска, а затем монопольную блокировку, или он получает монопольную блокировку с самого начала? Предполагая, что Read Committed, получает ли оператор UPDATE исключительную блокировку только на этапе записи или он получает ее, как только начинает чтение? Я использую PostgreSQL.


postgresql database concurrency locks
person raincloud    schedule 01.04.2021    source источник
comment
Я нашел dba-oracle.com/t_lock_types.htm для Oracle, так что я предполагаю что PostgreSQL аналогичным образом будет использовать монопольную блокировку только с начала выполнения оператора UPDATE. В обоих случаях доступ к данным не уменьшается из-за MVCC. Я предполагаю, что если бы общие блокировки использовались во время выполнения операторов UPDATE, документация упомянула бы об этом в postgresql.org/docs/current/explicit-locking.html.   -  person raincloud    schedule 01.04.2021

Ответы (1)


arrow_upward
1
arrow_downward

Когда PostgreSQL просматривает таблицу в поисках строк, соответствующих WHERE условию UPDATE, он вообще не блокирует строки. Только когда строка-кандидат найдена, она блокируется в режиме EXCLUSIVE. Если блокировка не может быть получена сразу, а UPDATE заблокирована, PostgreSQL ждет, пока не сможет получить блокировку, а затем снова читает строку. Поведение зависит от уровня изоляции:

  • с READ COMMITTED, если последняя версия строки по-прежнему удовлетворяет условию WHERE, она блокируется

  • с REPEATABLE READ или SERIALIZABLE, если строка изменилась, вы получите ошибку сериализации и должны повторить транзакцию

Все это хорошо задокументировано.

person Laurenz Albe    schedule 01.04.2021