уничтожьте-9 процесс пост-ГРЭС

voretaq7 ответ охватывает ключевые моменты, в том числе правильный способ завершения серверных ВМ , но я хотел бы добавить немного дополнительные объяснения.

kill -9 (т.е. SIGKILL ) никогда и никогда не должен быть вашим первым выбором по умолчанию . Это должно быть вашим последним средством, когда процесс не отвечает на свои обычные запросы на завершение работы и SIGTERM ( kill -15 ) не возымел действия. Это верно в отношении Pg и почти всего остального.

kill -9 не дает убитому процессу вообще никакой возможности произвести очистку.

Когда дело доходит до PostgreSQL, Pg видит поддержку, которая завершается kill -9 как подкрепленный крах . Он знает, что серверная часть могла повредить разделяемую память - потому что вы могли прервать ее на полпути, например, на полпути, написав страницу в shm или изменив ее - поэтому он завершает работу и перезапускает все остальные серверные части , когда замечает что серверная часть внезапно исчезла и завершилась с ненулевым кодом ошибки.

Вы увидите это в журналах.

Если кажется, что это не причиняет вреда, это потому, что Pg перезапускает все после сбоя и ваше приложение аккуратно восстанавливается после утерянных соединений. Это не очень хорошая идея. Если никакие другие сбои серверной части не тестируются хуже, чем нормально функционирующие части Pg, и они намного сложнее / разнообразнее, поэтому шансы на ошибку, скрывающуюся в обработке сбоев серверной части и восстановлении, выше.

BTW, если вы уничтожите -9 постмастера, затем удалите postmaster.pid и запустите его снова, не проверяя, что все postgres backend исчезли, могут быть случиться . Это могло легко произойти, если вы случайно убили постмастера вместо серверной части, увидели, что база данных перестала работать, попытались перезапустить ее, удалили «устаревший» файл .pid, когда перезапуск не удался, и попытались перезапустить его снова. Это одна из причин, по которой вам следует избегать использования kill -9 вокруг Pg и не удалять postmaster.pid .

Демонстрация:

Чтобы точно увидеть, что происходит когда вы kill -9 бэкэнд, попробуйте эти простые шаги. Откройте два терминала, откройте psql в каждом и при каждом запуске SELECT pg_backend_pid (); . В другом терминале kill -9 один из PID. Теперь снова запустите SELECT pg_backend_pid (); в обоих сеансах psql. Обратите внимание, как они оба потеряли связь?

Сессия 1, которую мы убили:

$ 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)

Сессия 2, которая была сопутствующим ущербом:

$ 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)

Посмотрите, как обе сессии были прерваны ? Вот почему вы не убиваете -9 бэкэнд.