我以前从未见过这个问题。我遇到了问题，许多 PostgreSQL 进程被卡住了，所以我用 -KILL 杀死了它们...
当我尝试重新启动时，它说它无法重新启动，但守护进程继续运行并使用少量处理器进行大量 I/O。它是否正在尝试修复数据库？
我根本没有得到任何日志。我认为有一种方法可以增加日志输出......我会研究一下。此时，连接到服务器的套接字没有被创建，但服务器没有退出或发出任何错误/消息，所以我不知道发生了什么！？
如果有人有线索，我会很高兴听到。
我遇到了问题，许多 postgresql 进程被卡住了，所以我用 -KILL 杀死了它们...
不要这样做。它不会导致数据损坏，但正如您发现的那样，它会强制整个数据库系统重新启动并进行崩溃恢复。
如果您使用SIGKILL( kill -9)硬杀死任何数据库后端，则 postmaster 必须假设共享内存可能已损坏，并且必须杀死并重新启动所有工作人员，进行崩溃恢复，就好像服务器本身已崩溃并重新启动一样。
您不应该需要SIGKILL后端。使用常规SIGTERM命令它停止正在执行的操作并退出 - 或者更好的是，pg_terminate_backend(...)在 SQL 中使用。如果后端没有响应，SIGQUIT应该强制它终止。
如果这样做SIGKILL，崩溃恢复通常需要几秒钟；一个非常大和繁忙的数据库的分钟。但是，如果您有一个漫长checkpoint_timeout而庞大的数据库，checkpoint_segments您可以积累大量必须在数据库再次可用之前完成的工作。如果您的磁盘 I/O 非常慢，情况会更糟。
PostgreSQL在恢复时确实会生成日志，并且它们处于日志级别，因此不太可能被抑制。所以很难说会发生什么。也许您正在查看 syslog，但是您的 PostgreSQL 安装配置为直接登录到datadir 目录中/var/log/pgsql或pg_log目录中的文件？
（对于阅读本文的其他人，永远不要 SIGKILL让 postmaster 然后删除 postmaster pid 文件并在仍然postgres运行旧的后端时重新启动 PostgreSQL 。这可能导致数据损坏，因为您已禁用 PostgreSQL 为阻止您而采取的所有安全措施在旧的后端可能仍在运行时启动一个新的 postmaster。）