Тип: | integer |
По умолчанию: | 0 (0ms) |
Минимальный: | 0 (0ms) |
Максимальный: | 2147483647 (2147483647ms) |
Ед. изм: | milliseconds (ms) |
Контекст: | user |
Перезапуск: | false |
От: | 9.3 |
Задаёт максимальную длительность ожидания (в миллисекундах) любым оператором получения блокировки таблицы, индекса, строки или другого объекта базы данных. Если ожидание не закончилось за указанное время, оператор прерывается. Это ограничение действует на каждую попытку получения блокировки по отдельности и применяется как к явным запросам блокировки (например, LOCK TABLE или SELECT FOR UPDATE без NOWAIT
), так и к неявным. Если log_min_error_statement имеет значение ERROR
или ниже, оператор, прерванный по тайм-ауту, будет также записан в журнал. При значении, равном нулю (по умолчанию), этот контроль длительности отключается.
В отличие от statement_timeout, этот тайм-аут может произойти только при ожидании блокировки. Заметьте, что при ненулевом statement_timeout бессмысленно задавать в lock_timeout
такое же или большее значение, так как тайм-аут оператора всегда будет происходить раньше.
Устанавливать значение lock_timeout
в postgresql.conf не рекомендуется, так как это повлияет на все сеансы.
Рекомендации [EN]
На StackOverflow
На pgsql-hackers
- Prolonged truncation phase during vacuum on toast table with repeated interruptions by lock waiters and a proposed POC patch
- Re: Add “FOR UPDATE NOWAIT” lock details to the log.
- Idea: lock_timeout scoped by lock types
- Re: Report search_path value back to the client.
- Add “FOR UPDATE NOWAIT” lock details to the log.