Блокировка Postgres ShareRowExclusiveLock

#postgresql #configuration #deadlock

#postgresql #конфигурация #взаимоблокировка

Вопрос:

У меня загружающийся сервер Postgres с большим количеством операций обновления. В Postgres.conf я установил deadlock_timeout=8s .

В журнале я вижу следующее:

 process 3588 acquired ShareRowExclusiveLock on relation 17360 of database 16392 after 
8000.000 ms
  

Это кажется действительно медленным. Каково ваше мнение по этому поводу? Есть ли лучшее значение для deadlock_timeout ? Какие еще настройки могут помочь сократить время блокировки? И в этой строке из журнала говорится, что транзакция была прервана и какие-либо данные не были обновлены?

Ответ №1:

Блокировки sharerowexclusivelock устанавливаются, когда вы явно выдаете LOCK TABLE инструкцию. Поведение по умолчанию для LOCK TABLE заключается в запросе эксклюзивного доступа к таблице: никто не сможет читать из нее, пока блокировка не будет снята.

PostgreSQL использует управление параллелизмом нескольких версий для обеспечения целостности транзакций в базе данных. Если вы не видите проблем с приложением, я предлагаю отключить явное использование LOCK TABLE или попытаться запустить операцию массового обновления в нерабочее время.

Я бы также посоветовал ознакомиться с документацией по явным блокировкам, если вам действительно нужно использовать явные блокировки.

Ответ №2:

Вы читали это?

http://www.postgresql.org/docs/current/static/runtime-config-locks.html

В идеале настройка должна превышать типичное время транзакции, чтобы повысить вероятность того, что блокировка будет снята до того, как официант решит проверить, нет ли взаимоблокировки.