Назад | Перейти на главную страницу

Что мне делать, если pg_cancel_backend не работает?

Что мне делать, если у меня долго выполняется запрос Postgres, и обычный «kill [pid]» не работает, а pg_cancel_backend не работает?

http://www.postgresql.org/docs/current/static/server-shutdown.html

pg_cancel_backend эквивалентен отправке SIGINT процессу.
pg_terminate_backend аналогично SIGTERM, но если pg_cancel_backend не работает, я не понимаю, почему pg_terminate_backend будет.

Если вы пробовали эти варианты, вы можете попробовать SIGQUIT. Документы говорят: "Это рекомендуется только в экстренных случаях."

(Если вы ненавидите свои данные и надеетесь, что они умрут, вы можете использовать SIGKILL. Но я бы не стал.)

Вы можете использовать либо kill прямо или pg_ctl kill.

Вам следует никогда kill -9 любой процесс postgres, если ваша цель - принудительно вывести из строя весь сервер. Вы можете убить любой процесс, который не отвечает на вызов pg_cancel_backend () из оболочки, с помощью

kill <pid>

т.е. не -9. Обратите внимание, что я видел несколько раз, когда даже это не работало из-за зависания процесса в каком-то цикле ожидания данных в сетевом соединении. Если я правильно помню, об этом позаботилось убийство клиентского процесса.

если у вас есть недавний Postgres, вы можете попробовать pg_terminate_backend вместо.

шарики правильно в своем заявлении выше ...

ЕСЛИ ты пытаешься SHUTDOWN сервер, хотя для меня:

Я просто пытаюсь удалить устаревшие базы данных / схемы, у которых все еще есть затяжное соединение, которое оно не отпускает.

Итак, чтобы ответить на ваш вопрос,

Если у меня есть длительный запрос Postgres ...

pg_cancel_backend не работает ...

что я должен делать?

НЕ ОТНОСИТСЯ выключить сервер любым способом.

Я также видел такое поведение pg_cancel_backend() не работает. И хотел поделиться своим рабочим решением.

Я пока не видел проблем с какой-либо «потерей» данных.

Опять же, я не пытаюсь убить Active запросов тоже.

- Я вошел в систему как ПОЛЬЗОВАТЕЛЬ «A» с сеансом или PID 777777.

- И собираюсь попытаться принудительно отключить еще один сеанс от ПОЛЬЗОВАТЕЛЯ «A», открытого как 123456789.

- Это спящее соединение, и поэтому я также ищу idle в моих запросах ниже.

SELECT * 
FROM pg_stat_activity 
WHERE pid = 123456789 
      AND STATE = 'idle';

- Попытка 1

SELECT pg_cancel_backend(pid) 
FROM pg_stat_activity 
WHERE pid = 123456789 
      AND STATE = 'idle';

- Достаточно интересный результат показывает, что отмена ИСТИНА, но все еще существует.

SELECT * 
FROM pg_stat_activity 
WHERE pid = 123456789 
      AND STATE = 'idle';

- Попытка 2

SELECT pg_terminate_backend(pid) 
FROM pg_stat_activity 
WHERE pid = 123456789 
      AND STATE = 'idle';

- А теперь его нет ..

SELECT * 
FROM pg_stat_activity 
WHERE pid = 123456789 
      AND STATE = 'idle';

- ПРИМЕЧАНИЕ: я пытался использовать нелепые идентификаторы pid #, чтобы помочь людям не копировать и вставлять и разрушать свою жизнь.

- ПРИМЕЧАНИЕ: по умолчанию postgres позволяет ТОЛЬКО убивать процессы, запущенные под ВАШИМ логированием в ПОЛЬЗОВАТЕЛЕ,

- ПРИМЕЧАНИЕ: но вы это уже знали.

Надеюсь это поможет. знак равно

~ Джей