¿Qué hago cuando pg_cancel_backend no funciona?

Si tengo una consulta de Postgres de larga duración, y "kill [pid]" no funciona, y pg_cancel_backend no funciona, ¿qué debo hacer?

Usted debe nunca se kill -9 cualquier postgres procesan a menos que su objetivo es llevar a todo el servidor hacia abajo por la fuerza. Puede eliminar cualquier proceso que no responda a una llamada pg_cancel_backend () desde el shell con

kill <pid>

es decir, no -9. Tenga en cuenta que he visto algunas veces que incluso eso no funcionó debido a que el proceso se colgó esperando en algún bucle los datos en una conexión de red. Si recuerdo correctamente, matar el proceso del cliente se encargó de eso.

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

pg_cancel_backend es equivalente a enviar SIGINT al proceso.
pg_terminate_backend del mismo modo para SIGTERM, pero si pg_cancel_backend no funciona, no veo por qué pg_terminate_backend lo haría.

Si ha probado esas opciones, puede probar SIGQUIT. Los documentos dicen: " Esto se recomienda solo en emergencias " .

(Si odias tus datos y esperas que mueran, podrías usar SIGKILL. Pero no lo haría).

Puedes usarlo killdirectamente o pg_ctl kill.

si tienes un Postgres reciente, puedes probarlo pg_terminate_backend.

Bribles es correcto en su declaración anterior ...

SinSHUTDOWN embargo, si intentas con el servidor, para mí:

Solo estoy tratando de eliminar las bases de datos / esquemas retirados, que todavía tienen una conexión persistente que no dejará pasar.

Entonces, para responder tu pregunta,

Si tengo una consulta de Postgres de larga duración ...

pg_cancel_backend no funciona ...

¿Qué tengo que hacer?

NO ESTÁ RELACIONADO con apagar el servidor de ninguna manera.

También he visto este comportamiento de pg_cancel_backend()no funcionar. Y quería compartir mi solución de trabajo.

No he visto un problema hasta ahora, con ningún tipo de "pérdida" de datos.

De nuevo, tampoco estoy tratando de matar Activeconsultas.

- Estoy conectado como USUARIO "A" con una sesión o PID de 777777.

- Y va a intentar forzar la desconexión de otra sesión del USUARIO "A" abierta como 123456789

- Que es una conexión inactiva, y es por eso que también busco idleen mis consultas a continuación.

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

- Intento 1

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

- Curiosamente, Result indica que la cancelación es VERDADERA, pero aún existe.

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

- Intento 2

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

- Y ahora no existe ...

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

- NOTA: Traté de usar pid # ridículos para ayudar a evitar que la gente copie y pegue y arruine sus vidas.

- NOTA: Por defecto, postgres SOLO le permitirá eliminar procesos que se ejecutan bajo SU inicio de sesión en el USUARIO,

- NOTA: pero eso ya lo sabías.

Espero que esto ayude. =)

~ Jay