# Client 等待

> PostgreSQL 等待应用、网络套接字、TLS/GSS 握手或复制客户端。
---

`Client` 颠倒了通常的怀疑方向：PostgreSQL 已准备好读取、写入或完成协议步骤，但远端或网络没有推进。连接池里的空闲连接很多时，大量 Client 等待往往完全正常。

## 状态与事务年龄决定严重度 {#how-to-read}

`ClientRead` 加 `state = 'idle'` 属于预期。同一个事件若是 `idle in transaction` 且 `xact_start` 很老，就可能保留锁、快照和死元组。活动会话上的 `ClientWrite` 则说明服务器无法足够快地把结果交给消费者。

- **正常：** 空闲池化连接等待下一条命令。
- **关注：** 很老的 `idle in transaction`、活动状态的 `ClientWrite`、握手等待，或应用延迟同步上升。
- **紧急：** 客户端停止消费结果、连接槽耗尽、打开的事务阻碍清理，或复制客户端反复断开。

## 值得先认出的事件 {#top-events}

| 事件 | 第一个责任方 |
| --- | --- |
| [ClientRead](client-read/) | 应用/连接池 |
| [ClientWrite](client-write/) | 应用消费者或网络 |
| [GssOpenServer](gss-open-server/) | 认证/网络路径 |
| [SslOpenServer](ssl-open-server/) | TLS 握手路径 |
| [LibpqwalreceiverReceive](libpqwalreceiver-receive/) | 上游主库/网络 |
| [WalSenderWriteData](wal-sender-write-data/) | 备库或复制客户端 |

## 常见误读 {#misreads}

- “大多数会话都在 ClientRead” 不是数据库瓶颈证据；还要看状态、事务年龄与连接池规模。
- 取消空闲客户端不能修复过大的连接池，只会让连接池重新连接。
- 即使数据库主机的网络看起来空闲，慢消费者仍会导致 `ClientWrite`。
- 带复制语义的 Client 等待仍位于协议边界，但运维责任方不同。

---

本节页面：

- [Client: ClientRead](/zh/client/client-read/): 等待从客户端读取数据。
- [Client: ClientWrite](/zh/client/client-write/): 等待向客户端写入数据。
- [Client: GssOpenServer](/zh/client/gss-open-server/): 建立 GSSAPI 会话时，等待从客户端读取数据。
- [Client: LibpqwalreceiverConnect](/zh/client/libpqwalreceiver-connect/): 在 WAL receiver 中等待与远程服务器建立连接。
- [Client: LibpqwalreceiverReceive](/zh/client/libpqwalreceiver-receive/): 在 WAL receiver 中等待从远程服务器接收数据。
- [Client: SslOpenServer](/zh/client/ssl-open-server/): 尝试建立连接时等待 SSL。
- [Client: WaitForStandbyConfirmation](/zh/client/wait-for-standby-confirmation/): 等待物理备库接收并刷写 WAL。
- [Client: WalSenderWaitForWal](/zh/client/wal-sender-wait-for-wal/): 在 WAL sender 进程中等待 WAL 完成刷写。
- [Client: WalSenderWriteData](/zh/client/wal-sender-write-data/): 在 WAL sender 进程中处理 WAL receiver 的回复时，等待发生任何活动。