La réponse de voretaq7 couvre les points clés, y compris la bonne façon de terminer les backends, mais je voudrais ajouter un peu plus d'explications.
kill -9
(c.-à-d. SIGKILL
) ne devrait jamais, jamais, jamais être votre premier choix par défaut . Cela devrait être votre dernier recours lorsque le processus ne répond pas à ses demandes d'arrêt normales et qu'un SIGTERM
( kill -15
) n'a eu aucun effet. C'est vrai pour Pg et à peu près tout le reste.
kill -9
ne donne aucune chance au processus tué de faire un nettoyage.
En ce qui concerne PostgreSQL, Pg voit un sauvegardé qui se termine par kill -9
un crash sauvegardé . Il sait que le backend a peut-être corrompu la mémoire partagée - parce que vous auriez pu l'interrompre à mi-chemin en écrivant une page dans shm ou en en modifiant un, par exemple - donc il termine et redémarre tous les autres backends quand il remarque qu'un backend a soudainement disparu et est sorti avec un code d'erreur non nul.
Vous verrez cela signalé dans les journaux.
Si cela ne semble pas faire de mal, c'est parce que Pg redémarre tout après le crash et que votre application se rétablit proprement des connexions perdues. Cela n'en fait pas une bonne idée. Si rien d'autre n'est bloqué, les tests backend sont moins bien testés que les parties de Pg fonctionnant normalement et sont beaucoup plus compliqués / variés, donc les chances d'un bug qui se cache dans la gestion et la récupération des crashs backend sont plus élevées.
BTW, si vous kill -9
le postmaster puis supprimez postmaster.pid
et redémarrez sans vous assurer que chaque postgres
backend a disparu, de très mauvaises choses peuvent se produire . Cela peut facilement se produire si vous avez accidentellement tué le maître de poste au lieu d'un serveur principal, vu que la base de données était en panne, essayé de la redémarrer, supprimé le fichier .pid "périmé" lorsque le redémarrage a échoué et essayé de la redémarrer à nouveau. C'est l'une des raisons pour lesquelles vous devriez éviter de faire signe kill -9
à Pg et ne pas supprimer postmaster.pid
.
Une démonstration:
Pour voir exactement ce qui se passe lorsque vous êtes kill -9
un backend, essayez ces étapes simples. Ouvrez deux terminaux, ouvrez psql dans chacun et à chaque exécution SELECT pg_backend_pid();
. Dans un autre terminal, l' kill -9
un des PID. Maintenant, exécutez SELECT pg_backend_pid();
à nouveau dans les deux sessions psql. Remarquez comment ils ont tous deux perdu leurs connexions?
Session 1, que nous avons tuée:
$ 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)
Session 2, qui portait sur les dommages collatéraux:
$ 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)
Vous voyez comment les deux sessions ont été interrompues? C'est pourquoi vous n'avez pas de kill -9
backend.