|
ExclusiveLock - норма?
|
|||
---|---|---|---|
#18+
Добрый вечер. Смотрю в: [SRC sql]SELECT relation::regclass,* FROM pg_locks[/SR0C] вижу несколько сессий с "ExclusiveLock" и locktype "virtualxid". Насколько понял, это "подготовленные транзакции". Скажите, это нормально они все "ExclusiveLock" создают? И как понять какой объект БД они блокируют? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.10.2017, 18:59 |
|
ExclusiveLock - норма?
|
|||
---|---|---|---|
#18+
acidophilus, Это нормально, читайте про типы локов: https://www.postgresql.org/docs/current/static/explicit-locking.html Объекты все есть в представлении в виде ID. Т.к. это глобальное представление, то увидеть названия таблиц можно только подключившись к соответствующей базе. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.10.2017, 19:11 |
|
ExclusiveLock - норма?
|
|||
---|---|---|---|
#18+
vyegorovacidophilus, Это нормально, читайте про типы локов: https://www.postgresql.org/docs/current/static/explicit-locking.html Объекты все есть в представлении в виде ID. Т.к. это глобальное представление, то увидеть названия таблиц можно только подключившись к соответствующей базе. Спасибо, почитаю. Но id у них пустой. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.10.2017, 19:14 |
|
ExclusiveLock - норма?
|
|||
---|---|---|---|
#18+
acidophilus, Есть там ID: Код: plaintext 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
12.10.2017, 20:14 |
|
ExclusiveLock - норма?
|
|||
---|---|---|---|
#18+
vyegorovacidophilus, Есть там ID: Код: plaintext 1.
А как найти что это за объект БД? Например, получаю virtualxid "121/100324" А SELECT 100324::oid::regclass ни в одной БД не выводит название таблицы. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2017, 13:22 |
|
ExclusiveLock - норма?
|
|||
---|---|---|---|
#18+
acidophilus, virtualxid — это идентификатор виртуальной транзакции, а не объект в базе. Для объекта будет не-NULL-увым поле `relation`. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2017, 13:55 |
|
ExclusiveLock - норма?
|
|||
---|---|---|---|
#18+
vyegorovacidophilus, virtualxid — это идентификатор виртуальной транзакции, а не объект в базе. Для объекта будет не-NULL-увым поле `relation`. Подскажите пожалуйста, как понять что блокируется? Просто в БД висят десятки таких сессий ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2017, 14:22 |
|
ExclusiveLock - норма?
|
|||
---|---|---|---|
#18+
acidophilus, Рекурсивный запрос в конце поста: http://blog.postgresql-consulting.com/2017/10/deep-dive-into-postgres-stats.html ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2017, 14:30 |
|
ExclusiveLock - норма?
|
|||
---|---|---|---|
#18+
vyegorovacidophilus, Рекурсивный запрос в конце поста: http://blog.postgresql-consulting.com/2017/10/deep-dive-into-postgres-stats.html Спасибо. Однако, ничего не выводит запрос: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2017, 14:38 |
|
ExclusiveLock - норма?
|
|||
---|---|---|---|
#18+
acidophilusА как найти что это за объект БД? Например, получаю virtualxid "121/100324" А SELECT 100324::oid::regclass ни в одной БД не выводит название таблицы. Строки с locktype=virtualxid ничего не блокируют. Каждый раз когда начинается транзакция, в pg_locks добавляется эта строчка и удаляется по завершении транзакции. Строка нужна для того, чтобы другие транзакции знали что эта транзакция еще живая и не завершена. Хотя документация говорит, что другие транзакции всё-таки могут за неё цепляться: "На протяжении транзакции серверный процесс удерживает исключительную блокировку виртуального идентификатора транзакции. Если транзакции назначается постоянный идентификатор (что обычно происходит, только если транзакция изменяет состояние базы данных), он также удерживает до её завершения блокировку этого постоянного идентификатора. Когда процесс находит необходимым ожидать именно какую-то другую транзакцию, он делает это, запрашивая разделяемую блокировку для идентификатора этой транзакции ( виртуального или постоянного, в зависимости от ситуации ). Этот запрос будет выполнен, только когда другая транзакция завершится и освободит свои блокировки." ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2017, 14:59 |
|
ExclusiveLock - норма?
|
|||
---|---|---|---|
#18+
Оставлю здесь, вдруг еще пригодится. Захотелось всё-таки разобраться зачем в pg_locks создаются строки с locktype=virtualxid. Что это за ситуации, когда транзакция еще не получившая "настоящий" номер (т.е. только читающая) может кого-то заблокировать. Вот что нашлось в исходниках : "Every transaction takes a lock on its own virtual transaction ID. Currently, the only operations that wait for these locks are CREATE INDEX CONCURRENTLY and Hot Standby (in the case of a conflict), so most VXID locks are taken and released by the owner without anyone else needing to care." Теперь идем в документацию на CREATE INDEX и читаем как выполняется CREATE INDEX CONCURRENTLY: "При параллельном построении индекса он попадает в системный каталог в одной транзакции, затем ещё два сканирования таблицы выполняются в двух других транзакциях. Перед каждым сканированием таблицы процедура построения индекса должна ждать завершения текущих транзакций, модифицировавших эту таблицу. После второго сканирования также необходимо дожидаться завершения всех транзакций, получивших снимок (см. Главу 13) перед вторым сканированием ." Вот оно что. Теперь можно и тестовый пример сделать. В первой транзакции с уровнем изоляции REPEATABLE READ (чтобы снимок подольше оставался) прочитаем строки из таблицы. А во второй после этого попытаемся создать индекс. Первый сеанс: Код: sql 1. 2. 3. 4. 5. 6. 7.
Второй сеанс: Код: sql 1.
И второй сеанс повисает. Теперь смотрим из третьего сеанса на блокировки: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Кстати, вышеупомянутый запрос Виктора эту блокировку, разумеется, тоже покажет: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30.
Пример с конфликтом на hot standby делать лениво. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2017, 16:59 |
|
|
start [/forum/topic.php?fid=53&fpage=62&tid=1996065]: |
0ms |
get settings: |
11ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
37ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
others: | 16ms |
total: | 154ms |
0 / 0 |