Câu trả lời của voretaq7 bao gồm các điểm chính, bao gồm cách chính xác để chấm dứt phụ trợ nhưng tôi muốn thêm một chút giải thích.
kill -9(tức là SIGKILL) không bao giờ, bao giờ, sẽ là mặc định lựa chọn đầu tiên của bạn . Nó sẽ là giải pháp cuối cùng của bạn khi quá trình không đáp ứng với các yêu cầu tắt máy thông thường của nó và SIGTERM( kill -15) không có hiệu lực. Điều đó đúng với PG và khá nhiều thứ khác.
kill -9 làm cho quá trình bị giết không có cơ hội để làm bất kỳ việc dọn dẹp nào cả.
Khi nói đến PostgreSQL, PG thấy một sự hỗ trợ bị chấm dứt bởi kill -9sự cố được hỗ trợ . Nó biết phần phụ trợ có thể đã bị hỏng bộ nhớ chia sẻ - vì bạn có thể đã làm gián đoạn nó nửa chừng bằng cách viết một trang thành shm hoặc sửa đổi một trang, chẳng hạn - vì vậy nó chấm dứt và khởi động lại tất cả các phần phụ trợ khác khi thông báo rằng phần phụ trợ đột nhiên biến mất và thoát với mã lỗi khác không.
Bạn sẽ thấy điều này được báo cáo trong nhật ký.
Nếu nó dường như không gây hại, thì bởi vì PG đang khởi động lại mọi thứ sau sự cố và ứng dụng của bạn đang phục hồi sạch sẽ từ các kết nối bị mất. Điều đó không làm cho nó một ý tưởng tốt. Nếu không có gì khác, các sự cố phụ trợ được kiểm tra ít hơn so với các bộ phận hoạt động bình thường của PG và phức tạp / đa dạng hơn nhiều, vì vậy khả năng xảy ra lỗi trong xử lý và phục hồi sự cố phụ trợ cao hơn.
BTW, nếu bạn kill -9là người quản lý bưu điện, sau đó loại bỏ postmaster.pidvà bắt đầu lại mà không đảm bảo mọi postgresphụ trợ đều biến mất, những điều rất xấu có thể xảy ra . Điều này có thể dễ dàng xảy ra nếu bạn vô tình giết chết người quản lý bưu điện thay vì phụ trợ, thấy cơ sở dữ liệu bị hỏng, cố gắng khởi động lại, xóa tệp .pid "cũ" khi khởi động lại thất bại và cố gắng khởi động lại. Đó là một trong những lý do bạn nên tránh vẫy tay chào kill -9và không nên xóa postmaster.pid.
Một cuộc biểu tình:
Để xem chính xác những gì xảy ra khi bạn kill -9phụ trợ, hãy thử các bước đơn giản sau. Mở hai thiết bị đầu cuối, mở psql trong mỗi thiết bị và trong mỗi lần chạy SELECT pg_backend_pid();. Trong một thiết bị đầu cuối khác, kill -9một trong các PID. Bây giờ chạy SELECT pg_backend_pid();trong cả hai phiên psql một lần nữa. Chú ý làm thế nào cả hai mất kết nối của họ?
Phần 1, mà chúng tôi đã giết:
$ 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)
Phần 2, đó là thiệt hại tài sản thế chấp:
$ 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)
Xem làm thế nào cả hai phiên bị phá vỡ? Đó là lý do tại sao bạn không kill -9phụ trợ.