La respuesta de voretaq7 cubre los puntos clave, incluida la forma correcta de terminar los backends, pero me gustaría agregar un poco más de explicación.
kill -9(es decir SIGKILL) nunca, nunca, debería ser su opción predeterminada por primera vez . Debería ser su último recurso cuando el proceso no responde a sus solicitudes de apagado normales y a SIGTERM( kill -15) no ha tenido ningún efecto. Eso es cierto para Pg y casi todo lo demás.
kill -9 no le da ninguna oportunidad al proceso final de realizar ninguna limpieza.
Cuando se trata de PostgreSQL, Pg ve un respaldo que termina kill -9como un bloqueo respaldado . Sabe que el backend podría haber dañado la memoria compartida, porque podría haberlo interrumpido a mitad de camino al escribir una página en shm o modificar una, por ejemplo, por lo que termina y reinicia todos los demás backend cuando se da cuenta de que un backend se ha desvanecido repentinamente y salió con un código de error distinto de cero.
Verá esto informado en los registros.
Si parece no hacer daño, eso se debe a que Pg está reiniciando todo después del bloqueo y su aplicación se está recuperando limpiamente de las conexiones perdidas. Eso no lo hace una buena idea. Si nada más, los bloqueos del backend están menos probados que las partes de funcionamiento normal de Pg y son mucho más complicados / variados, por lo que las posibilidades de un error al acecho en el manejo y la recuperación del crash del backend son mayores.
Por cierto, si usted es kill -9el administrador de correo, elimínelo postmaster.pidy vuelva a iniciarlo sin asegurarse de que todos los postgresservidores hayan desaparecido, pueden suceder cosas muy malas . Esto podría suceder fácilmente si accidentalmente eliminó al administrador de correo en lugar de un servidor, vio que la base de datos se había caído, intentó reiniciarlo, eliminó el archivo .pid "obsoleto" cuando el reinicio falló e intentó reiniciarlo nuevamente. Esa es una de las razones por las que debe evitar agitar la página kill -9y no debe eliminarla postmaster.pid.
Una demostración:
Para ver exactamente qué sucede cuando kill -9un back-end, intente estos simples pasos. Abra dos terminales, abra psql en cada una y en cada ejecución SELECT pg_backend_pid();. En otro terminal, kill -9uno de los PID. Ahora ejecute SELECT pg_backend_pid();en ambas sesiones psql nuevamente. ¿Notan cómo ambos perdieron sus conexiones?
Sesión 1, que matamos:
$ psql regress
psql (9.1.4)
Type "help" for help.
regress=# select pg_backend_pid();
pg_backend_pid
----------------
6357
(1 row)
[kill -9 of session one happens at this point]
regress=# select pg_backend_pid();
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.
regress=# select pg_backend_pid();
pg_backend_pid
----------------
6463
(1 row)
Sesión 2, que fue daño colateral:
$ psql regress
psql (9.1.4)
Type "help" for help.
regress=# select pg_backend_pid();
pg_backend_pid
----------------
6283
(1 row)
[kill -9 of session one happens at this point]
regress=# select pg_backend_pid();
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and repeat your command.
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.
regress=# select pg_backend_pid();
pg_backend_pid
----------------
6464
(1 row)
¿Ves cómo se rompieron ambas sesiones? Por eso no tienes kill -9un backend.