Есть парочку запросов
1.Блокированный
1.1 update asgufmsg set status = 1, sended = now(), modified = now(), rcount = rcount + 1 where id = $1
1.2 select s.id, s.message, s.messageId from asgufmsg s join asgufmsg r on (s.servicenumber = r.servicenumber and r.type = 1 and r.status = 2 and r.asgufcode = 0) where s.status = 0 and s.type = 2 and (select count(*) from asgufmsg where servicenumber = s.servicenumber and type = 2 and (asgufcode <> 0 or asgufcode is null) and created < s.created) = 0 order by s.created asc limit 500
2.Блокирующий
UPDATE asgufmsg set asgufcode = $1, asguftext = $2, modified = now(), status = $3 where servicenumber = $4 and messageId = $5
На момент моей проверки блокирующий запрос висел со старта порядка 6 минут, они достаточно часто проливаются и меняют статусы в этой таблице.

Я пока осваиваюсь в Postgres И после целодневного вчерашнего сёрфа по моим вопросам,всё таки решил обратиться к знающим людям:
1.Как посмотреть список выполняемых запросов к таблице asgufmsg
2.Могу ли я как то узнать из базы что скрывается за аргументами(параметрами) под $1 $2 $3 $3 итд (тоесть можно ли сделать выборку всех используемых аргументов базой или конкретным запросом)
3.Как лучше всего устранить взаимную блокировку и вообще что посоветуете на эту тему поизучать.Спасибо большое заранее

Alexius,Спасибо за комментарий но как я выяснил и предполагаю блокировки возникают не постоянно а периодически,где-то раз в 10-12 минут и судя по всему это связано с одновременным доступом нескольких скриптов к одной и той же строке и её апдейт либо селект.

Я вот задумался как до для разных скриптов можно разграничить доступ к таблице или приорит изацию настроить как-то?

Добавил пример лока,он возникает регулярно
И во время него скрипт повисает на минут 8.

При этом по плану он достаточно быстро выполняется.

Интересует как правильно разрешить такую блокировку?Чтобы она не возобновлялась и какой дополнительный анализ можно сделать?

vyegorov,Да на уровне приложения образуются очереди из за этой задержки.


locked_item waiting_duration blocked_pid blocked_query blocked_mode blocking_pid blocking_query blocking_mode
transactionid 00:02:05.651379 25 091 UPDATE asgufmsg set asgufcode = $1, asguftext = $2, modified = now(), status = $3 where servicenumber = $4 and messageId = $5 ShareLock 7 856 update asgufmsg set status = 1, sended = now(), modified = now(), rcount = rcount + 1 where id = $1 ExclusiveLock


вы имеете ввиду так?

Maxim Boguk,Точно этот вот скрин из баджера,записей много обрабатывает,табличка в которую он пишет весит за 20gb.

Strippett,вот из активити кусочек тот запрос висит в wait и ожидает завершения второй транзакции.

Strippett,По индексу я с вами согласен ,я уже его заготовил но не думаю что в нём дело.Там есть индекс если вы в Execute Plan видели по сервайс намбер. Если планом прогонять запрос ,то получается очень быстрое выполнение.Я ещё грешу на сторону приложения.
Можно ли как-то мне на уровне базы разрешать эти блокировки как-то автоматически пока не найду централизованное решение и истинную причину?

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