Postgres SIGKILL 崩溃

Question

仅供参考；这不需要答案。

我在负载很重的 Postgres 服务器上工作，并发出了挂起的 GRANT 命令。它没有被任何其他命令阻止。 我有几个打开的连接，并且能够使用普通的 pg_cancel_backend (SIGTERM) 命令杀死几个进程，但是我的 GRANT 命令没有响应该命令或 pg_terminate_backend (SIGINT)。我终于尝试了“kill -9 (pid)” (SIGKILL) 并且服务器崩溃了。

向数据库服务器进程或 postmaster 发出 SIGKILL 可能会导致崩溃——这是有据可查的。对子进程运行 SIGKILL 可能也使数据库崩溃。

Answer 1

对子进程运行 SIGKILL 也会导致数据库崩溃

任何在没有机会清理的情况下终止任何后端的致命信号，例如SIGSEGV、SIGABRT、SIGKILL 等，都会导致邮件管理员认为共享内存可能已损坏。它将回滚所有事务，终止所有正在运行的后端，然后重新启动。

PostgreSQL 这样做是为了保护您的数据。如果在后端崩溃之前出现问题导致它在共享内存上乱涂乱画，那么shared_buffers 可能包含无效数据，这些数据会被刷新到磁盘并替换好页面。

我很确定那是在文档中，但我能找到的只是我认为你在 shutting down the server 中所指的内容。

无论如何，如果你 SIGKILL 一个后端，你会看到类似：

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.

如果 OOM 杀手杀死后端也会发生这种情况，这就是为什么您应该在 Linux 上关闭内存过量使用。

我写了一些guidance on things to do and not to do with PostgreSQL on my blog。值得一看。