postmaster

PostgreSQL 的多进程架构相对于多线程架构有什么优势？如果你认同 “一个查询的后端进程崩溃不会影响其它连接的后端进程，从而提高了系统稳定性” 是其中一个优势，那请继续看下去 🐘。 postmaster 状态机 postmaster 作为 PostgreSQL 的主进程，在启动时负责创建共享内存和信号量。然而，它自身几乎不直接操作这些资源（当然也有例外，如 PMSignalState），这样的设计使得 postmaster 逻辑更简单、更可靠。当后端进程崩溃时，postmaster 通过重置共享内存和信号量来恢复系统的正常运行。 当 postmaster 接收到客户端请求时，它会立即派生（fork）一个子进程。子进程负责对请求进行权限验证，如果验证成功，则成为一个后端进程，这种设计保证了客户端请求的高效处理。 postmaster 负责启动一系列子进程，包括辅助（Auxilary）进程和普通（Normal）后端进程，其中 startup 进程跟 postmaster 紧密合作来保证数据库的一致性，它调用 StartupXLOG 执行数据库恢复的流程（本文不展开 recovery 的流程）。 postmaster 被实现为一个状态机，父子进程之间通过信号（signal）进行交互，如下是 postmaster 的状态图: postmaster 启动后初始状态为 PM_INIT，完成一些初始化工作后，启动 startup 进程，postmaster 进入 PM_STARTUP 状态 如果 startup 进程完成其工作并正常退出（OS 给 postmaster 发送 SIGCHLD 信号），postmaster 进入 PM_RUN 状态 startup 进程在进行到可以开始 archive recovery 时，给 postmaster 发信号并在共享内存标记 PMSIGNAL_RECOVERY_STARTED，postmaster 处理后进入 PM_RECOVERY 状态 startup 持续重放 wal 日志，如果开启了 Hot Standby，当达到一致状态后，会标记 PMSIGNAL_BEGIN_HOT_STANDBY，postmaster 进入 PM_HOT_STANDBY 状态 postmaster 在 PM_RUN 和 PM_HOT_STANDBY 状态都可以接收请求连接，因此这里把两个状态放在了一起 当有后端进程异常退出后，postmaster 进入 PM_WAIT_BACKENDS 状态，并调用 HandleChildCrash 来通知其它进程退出 所有进程退出后，postmaster 进入 PM_NO_CHILDREN 状态，然后重建共享内存和信号量并启动 startup 进程，postmaster 状态改为 PM_STARTUP 可以看出，一个后端进程的异常退出会影响其它子进程。一个简单的验证方法是使用 kill -9 去杀死一个查询的后端进程，并查看其它后端进程的 pid 是否改变，参考 KILL -9 EXPLAINED FOR POSTGRESQL。...