Greg Sabino Mullane：Postgres 无法启动：输出缺失之谜
内容提要
某客户新建的PostgreSQL集群在Kubernetes节点上无法启动且无日志。作者以单用户模式运行postgres可执行文件调试，发现进程因总线错误崩溃。排查确认是Linux内核大页内存缺陷：内核先允许分配内存，使用时却触发SIGBUS。关闭huge_pages后数据库正常启动。升级内核可修复，建议保持huge_pages为try。
延伸解读
无输出故障的排查思路
当Postgres启动失败且没有任何日志输出时，问题可能发生在日志收集器启动之前。本文案例中，作者通过直接运行postgres可执行文件并启用单用户模式，迅速定位到总线错误。这提示我们，在常规日志缺失时，应尝试更低层次的调试手段，例如直接运行核心进程或提高调试级别，以捕获早期崩溃信息。
大页内存与内核缺陷的关联
总线错误通常与内存访问异常有关。本文中，Postgres请求共享内存后触发SIGBUS，根源是Linux内核大页内存缺陷：内核允许分配内存，但实际使用时却拒绝访问。这提醒我们，在遇到神秘的内存相关崩溃时，除了SELinux，还应考虑大页内存配置及内核版本。
huge_pages配置的实践建议
Postgres默认huge_pages=try，旨在平衡性能与兼容性。本文案例中，临时关闭大页内存使数据库成功启动，证实了问题所在。作者建议保持try设置，除非能证明其导致问题。这告诉我们，在排查启动故障时，可尝试用命令行参数覆盖配置，快速验证大页内存的影响。
内核升级与长期修复
该问题源于Linux内核4.18版本的一个缺陷，已在后续版本中修复。作者验证了升级内核后可重新启用大页内存。这强调了保持系统组件更新的重要性。对于使用Kubernetes等复杂环境的用户，定期更新内核不仅能修复已知缺陷，还能避免类似隐蔽故障。
Q&A
PostgreSQL 集群在 Kubernetes 节点上启动失败且没有任何日志输出，可能是什么原因？
可能是 Linux 内核大页内存（huge pages）缺陷导致的。内核允许分配内存，但实际使用时触发 SIGBUS 信号，导致进程崩溃且无输出。
如何调试 PostgreSQL 启动时无输出且崩溃的问题？
可以直接运行 postgres 可执行文件，使用单用户模式（--single）并指定数据目录，例如：bin/postgres --single -D data。这样可以简化环境，快速暴露底层错误。
PostgreSQL 启动时出现 Bus Error 和核心转储，该如何解决？
可以尝试关闭 huge_pages。在命令行中强制设置 --huge_pages=off 启动，如果成功，则将 postgresql.conf 中的 huge_pages 改为 off 或升级内核。
huge_pages 在 PostgreSQL 中有什么作用？为什么建议保持为 try？
huge_pages 允许内核使用更大的内存块，减少内存管理开销。默认值为 try，建议保持，除非能证明它导致问题，因为大页通常有益。
Linux 内核大页缺陷导致 PostgreSQL 崩溃，如何彻底修复？
升级 Linux 内核到已修复的版本（如 4.18.0.513 之后），然后将 huge_pages 改回 try 即可。
从这次 PostgreSQL 启动故障中能总结出哪些经验教训？
1. 故障排查从复杂到简单，可直接运行 postgres 可执行文件；2. 整个技术栈都可能影响数据库；3. 保持系统更新；4. 大页通常有益，保持 try 除非证明有问题。
