|
|
|
pg_advisory_lock - странное сообщение
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. В процессе работы по нужде был прибит долгий скрипт, в котором вызывалось Код: sql 1. Необходимо было снять эту блокировку из другого соединения. Вот тут-то и возникла трабла. Вызовом pg_advisory_unlock она не снималась, выдавалось сообщение Код: plaintext Вызов pg_advisory_unlock_all() также не помог, блокировка не снималась. Потом, на всякий случай перед этими вызовами я пробовал Код: sql 1. в той же сессии из которой вызывалось unlock, при этом этот запрос зависал с флагом wait. Причём, сам запрос можно было отменить, но сам по себе он не "отлипал". Даже если я рвал остальные коннекты, где применялась эта фича. Наконец, на сервере выполнил service postgresql reload после этого вызывал pg_advisory_lock с тем номером, который требовался освободить, получал false, но уже без warning, после чего уже вызовом Код: sql 1. блокировка штатно снималась. Вопрос - есть ли более изящное решение, чтобы освободить нумерок? Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2014, 14:19:05 |
|
||
|
pg_advisory_lock - странное сообщение
|
|||
|---|---|---|---|
|
#18+
ОКТОГЕНЗдравствуйте. В процессе работы по нужде был прибит долгий скрипт, в котором вызывалось Код: sql 1. Необходимо было снять эту блокировку из другого соединения. Вот тут-то и возникла трабла. Вызовом pg_advisory_unlock она не снималась, выдавалось сообщение Код: plaintext Вызов pg_advisory_unlock_all() также не помог, блокировка не снималась. Потом, на всякий случай перед этими вызовами я пробовал Код: sql 1. в той же сессии из которой вызывалось unlock, при этом этот запрос зависал с флагом wait. Причём, сам запрос можно было отменить, но сам по себе он не "отлипал". Даже если я рвал остальные коннекты, где применялась эта фича. Наконец, на сервере выполнил service postgresql reload после этого вызывал pg_advisory_lock с тем номером, который требовался освободить, получал false, но уже без warning, после чего уже вызовом Код: sql 1. блокировка штатно снималась. Вопрос - есть ли более изящное решение, чтобы освободить нумерок? Код: plaintext уважаемый троцкей, перелогиньтесь RTFMpg_advisory_lock(key bigint) void Obtain exclusive session level advisory lock false вы можете получить из-по try -модификаций ф-й. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2014, 14:35:50 |
|
||
|
pg_advisory_lock - странное сообщение
|
|||
|---|---|---|---|
|
#18+
ОКТОГЕН, авторВопрос - есть ли более изящное решение, чтобы освободить нумерок? Снять через pg_terminate_backend(pid) сессию которая тот advisory lock держит (внимание - superuser only... если от обычного пользователя надо делайте security definer обертку). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2014, 14:40:22 |
|
||
|
pg_advisory_lock - странное сообщение
|
|||
|---|---|---|---|
|
#18+
ОКТОГЕН, Maxim Boguk подсказывает правильное решение - вы убили скрипт, но не убили сессию с БД, в которой этот лок до сих пор захвачен. просто маленькое уточнение - pg_terminate_backend можно запускать для сессий от того же пользователя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2014, 16:50:47 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=38716006&tid=1998543]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
158ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
40ms |
get tp. blocked users: |
1ms |
| others: | 237ms |
| total: | 476ms |

| 0 / 0 |
