При поддержке сервера БД бывает необходимо узнать, какие именно процессы нагружают сервер и возможно блокируют доступ к таблицам.
К примеру, если выполняется pgsql-функция F1, блокирующая таблицу X, с типом блокировки AccessExclusiveLock, то посмотреть содержимое данной таблицы можно будет только после завершения F1. Чтобы узнать, что функция F1 выполняется в настоящее время, я использую следующий макрос для pgAdmin, запрашивающий список задач из системной таблицы pg_stat_activity:
SELECT datname,
NOW() - query_start AS duration,
pid,
query
FROM pg_stat_activity
ORDER BY duration DESC;
Это макрос (запрос) выводит таблицу со списком выполняемых на сервере Postgresql запросов, отсортированную по продолжительности выполнения данных запросов.
Если нужно завершить нежелательный запрос, я копирую его pid, вставляю в окно Query, выделяю данную строку и выполняю следующий макрос:
SELECT pg_cancel_backend($SELECTION$);
После этого большинство запросов завершает работу, чему можно легко убедиться, если выполнить первый макрос еще раз.
Однако бывают такие запросы или функции, которые нельзя быстро завершить таким методом. По моим наблюдениям, это касается особо затратных для системы рекурсивных запросов на основе Common table expressions (CTE) и функций, использующих рекурсивные CTE. Возможно это связано с тем, что рекурсия использует стек, обнуление которого медленное и это тормозит завершение кода. В таком случае я обычно использую завершение процесса на уровне операционной системы. Я авторизуюсь через security shell непосредственно на сервере БД (FreeBSD).
Далее запрашиваю список процессов Postgresql:
ps -aux | grep pgsql
убеждаюсь по совпадающему pid, что среди них есть процесс нежелательного запроса и завершаю его с помощью команды:
kill pid
, где pid - числовой идентификатор из одноименного столбца, полученный при выполнении первого макроса.
Конечно можно сказать, что вместо макросов можно использовать обыкновенные запросы, сохраненные в каком-нибудь файле, однако макросы всегда под рукой и это гораздо удобнее.
