Client 等待
PostgreSQL 等待应用、网络套接字、TLS/GSS 握手或复制客户端。
Client 颠倒了通常的怀疑方向：PostgreSQL 已准备好读取、写入或完成协议步骤，但远端或网络没有推进。连接池里的空闲连接很多时，大量 Client 等待往往完全正常。
状态与事务年龄决定严重度
ClientRead 加 state = 'idle' 属于预期。同一个事件若是 idle in transaction 且 xact_start 很老，就可能保留锁、快照和死元组。活动会话上的 ClientWrite 则说明服务器无法足够快地把结果交给消费者。
- 正常： 空闲池化连接等待下一条命令。
- 关注： 很老的
idle in transaction、活动状态的ClientWrite、握手等待，或应用延迟同步上升。 - 紧急： 客户端停止消费结果、连接槽耗尽、打开的事务阻碍清理，或复制客户端反复断开。
值得先认出的事件
| 事件 | 第一个责任方 |
|---|---|
| ClientRead | 应用/连接池 |
| ClientWrite | 应用消费者或网络 |
| GssOpenServer | 认证/网络路径 |
| SslOpenServer | TLS 握手路径 |
| LibpqwalreceiverReceive | 上游主库/网络 |
| WalSenderWriteData | 备库或复制客户端 |
常见误读
- “大多数会话都在 ClientRead” 不是数据库瓶颈证据；还要看状态、事务年龄与连接池规模。
- 取消空闲客户端不能修复过大的连接池，只会让连接池重新连接。
- 即使数据库主机的网络看起来空闲，慢消费者仍会导致
ClientWrite。 - 带复制语义的 Client 等待仍位于协议边界，但运维责任方不同。
等待从客户端读取数据。
等待向客户端写入数据。
建立 GSSAPI 会话时，等待从客户端读取数据。
在 WAL receiver 中等待与远程服务器建立连接。
在 WAL receiver 中等待从远程服务器接收数据。
尝试建立连接时等待 SSL。
等待物理备库接收并刷写 WAL。
在 WAL sender 进程中等待 WAL 完成刷写。
在 WAL sender 进程中处理 WAL receiver 的回复时，等待发生任何活动。