PostgreSQL中client backend职责与连接对应关系问题

前置认知 #

我已明确background writer、checkpointer、walwriter、parallel_worker几类进程的区别，相关参考主题如下：

• wal writer vs bg writer vs checkpointer
• client_backend vs parallel_worker

我在使用opensnoop和trace工具观测进程IO行为时发现，client backend通常会调用pwrite(2)同时向数据文件和WAL文件写入内容，观测结果如下：

PID                     COMM               FD ERR PATH
18365 (client backend)  postgres           51   0 base/16384/16403
18365 (client backend)  postgres           52   0 pg_wal/0000000100000001000000E1

问题 #

1. client backend进程的主要职责是什么？
2. 是否每个数据库连接最多对应一个client backend进程？

解答 #

1. client backend进程的主要职责 #

client backend是PostgreSQL中直接服务于服务端连接会话的工作进程，核心职责可以概括为三类：

• 全链路处理客户端请求：从连接建立后的认证、SQL解析、执行计划生成、查询/写入逻辑执行，到最终结果集返回客户端，整个会话生命周期内的所有用户操作，都由对应绑定的client backend进程主导完成。
• 按需执行IO操作：观测到它同时写数据文件和WAL文件属于完全正常的行为，后台进程并不垄断IO写入：
  • WAL写入层面：walwriter的作用是批量后台刷WAL减少前台阻塞，但当事务提交时，如果当前事务的WAL记录还没被walwriter刷到磁盘，client backend会主动触发WAL写入+刷盘动作，保证事务持久性——WAL刷盘是事务提交的硬要求，不能完全等后台进程异步处理。
  • 数据文件写入层面：background writer、checkpointer的作用是后台批量刷脏页，减少前台进程的IO等待，但如果client backend在访问共享缓冲区时，需要淘汰脏页腾出空间加载新页，或者执行表扩展、批量写入、unlogged表操作等场景，也会直接向对应数据文件执行写入。
• 会话生命周期管理：维护会话级内存上下文、持有的锁、临时对象、会话级参数配置，处理事务提交/回滚逻辑，在执行并行查询时作为leader进程拉起、调度parallel_worker协同完成计算任务。

2. 数据库连接和client backend的对应关系 #

在PostgreSQL原生的进程架构下，每个连到PostgreSQL服务端的独立连接，同一时间最多对应1个client backend进程，二者默认是1:1绑定的关系：客户端连接发起后，postmaster主进程会fork出专属的client backend进程服务该连接，连接断开时对应的backend进程会随之退出，不存在一个backend同时服务多个服务端连接的情况。
有两个容易混淆的边界场景需要说明：

• 并行查询拉起的parallel_worker是client backend的子辅助进程，并不直接对接客户端，不属于client backend范畴，最终结果还是由绑定连接的client backend汇总后返回给客户端，不打破1:1的绑定关系。
• 如果使用PgBouncer这类外置连接池做事务级/语句级连接复用，本质是连接池在客户端和PostgreSQL之间做了连接转发，对PostgreSQL服务端本身来说，每个和服务端建立的后端连接依然对应一个独立的client backend，只是这些backend会被连接池调度，轮流给不同的客户端连接提供服务。

内容的提问来源于stack exchange，提问作者Tim He