Cómo matar una consulta (o conexión) en PostgreSQL
Dos funciones, una ruta de escalada: pg_cancel_backend(pid) cancela la consulta en ejecución y deja viva la conexión; pg_terminate_backend(pid) cierra toda la conexión. Empieza por cancelar.
-- 1. Encuentra el pid (ver la guía "show running queries" para más):
SELECT pid, state, now() - query_start AS runtime, left(query, 100)
FROM pg_stat_activity
WHERE state = 'active'
ORDER BY query_start;
-- 2. Cancela la consulta (suave — la sesión sigue conectada):
SELECT pg_cancel_backend(12345);
-- 3. Si no basta, cierra la conexión:
SELECT pg_terminate_backend(12345);Cuál usar y cuándo
| Situación | Usar |
|---|---|
| Una consulta es lenta / bloquea a otras, pero la sesión por lo demás está bien | pg_cancel_backend |
Sesión atascada idle in transaction reteniendo bloqueos (no hay nada en ejecución que cancelar) | pg_terminate_backend — cancelar no hace nada aquí: no hay ninguna consulta que cancelar, lo que perjudica es la transacción abierta |
| Sesión descontrolada que se reconecta y vuelve a lanzar la consulta | Termínala, luego arregla el cliente — matarla en bucle no es una estrategia |
Ambas devuelven true si se envió la señal (no es una garantía de que la consulta muera al instante — la cancelación se comprueba en puntos seguros, así que una consulta atascada en una llamada al kernel no interrumpible puede tardar un momento). La víctima recibe SQLSTATE 57014 ("canceling statement due to user request") o, cuando se termina, su cliente ve que la conexión se cae.
Limpieza masiva, hecha con cuidado
-- Termina todas las sesiones "idle in transaction" de más de 10 minutos:
SELECT pid, pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE state = 'idle in transaction'
AND xact_start < now() - interval '10 minutes';Ejecuta primero el SELECT sin la llamada a pg_terminate_backend y lee la lista — entonces, y solo entonces, añade el kill. Para una solución permanente, configura idle_in_transaction_session_timeout en lugar de ejecutar esto a mano en cada incidente.
Qué no hacer nunca
Nunca hagas kill -9 a un proceso backend de PostgreSQL desde la shell. Un backend con SIGKILL no puede limpiar su estado en la memoria compartida, así que el postmaster debe asumir que hay corrupción y reinicia todo el clúster, desconectando a todos y reproduciendo el WAL. Lo que parecía matar una sola consulta se convierte en una caída total. Un kill <pid> simple (SIGTERM) es equivalente a pg_terminate_backend y es aceptable cuando no puedes conseguir una conexión — pero las funciones SQL siempre son preferibles porque no pueden alcanzar el proceso equivocado.
Permisos: siempre puedes cancelar/terminar tus propias sesiones; para las sesiones de otros usuarios necesitas pertenecer a pg_signal_backend (o ser superusuario).