O que faço quando o pg_cancel_backend não funciona?

Se eu tiver uma consulta de longa duração no Postgres e "kill [pid]" regular não funcionar, e pg_cancel_backend não funcionar, o que devo fazer?

Você nunca deve matar -9 qualquer processo do postgres, a menos que seu objetivo seja derrubar o servidor inteiro à força. Você pode matar qualquer processo que não responda a uma chamada pg_cancel_backend () do shell com

kill <pid>

ou seja, não -9. Observe que eu já vi algumas vezes em que nem isso funcionou devido ao processo ser interrompido, aguardando em algum loop pelos dados em uma conexão de rede. Se bem me lembro, matar o processo do cliente cuidava disso.

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

pg_cancel_backend é equivalente a enviar SIGINT para o processo.
pg_terminate_backend da mesma forma para o SIGTERM, mas se pg_cancel_backend não estiver funcionando, não vejo por que pg_terminate_backend funcionaria.

Se você tentou essas opções, pode tentar SIGQUIT. Os documentos dizem: " Isso é recomendado apenas em emergências " .

(Se você odeia seus dados e espera que eles morram, você pode usar o SIGKILL. Mas eu não.)

Você pode usar killdiretamente ou pg_ctl kill.

Se você possui um Postgres recente, pode tentar pg_terminate_backend.

subornos está correto em sua declaração acima ...

Se você está tentando SHUTDOWNo servidor, para mim, porém:

Estou apenas tentando remover bancos de dados / esquemas aposentados, que ainda têm uma conexão persistente que não será liberada.

Então, para responder sua pergunta,

Se eu tiver uma consulta de longa duração no Postgres ...

pg_cancel_backend não funciona ...

O que devo fazer?

NÃO RELACIONADO a desligar o servidor de qualquer forma.

Eu também vi esse comportamento de pg_cancel_backend()não funcionar. E queria compartilhar minha solução de trabalho.

Eu não vi um problema até agora, com qualquer tipo de "perda" de dados.

Novamente, também não estou tentando matar Activeconsultas.

- Estou logado como USUÁRIO "A" com uma sessão ou PID 777777.

- E tentar forçar desconectar outra sessão do USUÁRIO "A", aberta como 123456789

- Que é uma conexão adormecida e é por isso que também procuro idlenas minhas consultas abaixo.

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

- tentativa 1

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

- O resultado interessante é que o cancelamento é VERDADEIRO, mas ainda existe.

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

- Tentativa 2

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

- E agora não existe ..

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

- NOTA: Tentei usar pid ridículos para ajudar a impedir que as pessoas copiassem, colassem e destruíssem suas vidas.

- OBSERVAÇÃO: por padrão, o postgres SOMENTE permitirá que você elimine processos em execução sob SEU login no USUÁRIO,

- NOTA: mas você já sabia disso.

Espero que isto ajude. =)

~ Jay