Client waits
Client flips the usual suspicion: PostgreSQL is ready to read, write, or complete a protocol step, and the remote side or network has not progressed. A large client-wait population is often normal for pooled idle connections.
State and transaction age decide severity
ClientRead plus state = 'idle' is expected. The same event with idle in transaction and an old xact_start can retain locks, snapshots, and dead tuples. ClientWrite on active sessions suggests the server cannot hand results to the consumer fast enough.
- Normal: idle pooled sessions waiting for the next command.
- Watch: old
idle in transaction, activeClientWrite, handshake waits, or application latency at the same time. - Urgent: clients stop consuming results, connection slots are exhausted, open transactions block cleanup, or a replication client disconnects repeatedly.
Events to recognize
| Event | First owner to contact |
|---|---|
| ClientRead | Application/connection pool |
| ClientWrite | Application consumer or network |
| GssOpenServer | Authentication/network path |
| SslOpenServer | TLS handshake path |
| LibpqwalreceiverReceive | Upstream primary/network |
| WalSenderWriteData | Standby or replication client |
Common misreads
- “Most sessions are in ClientRead” is not a database bottleneck without state, transaction age, and pool sizing.
- Cancelling an idle client does not fix an oversized pool; it only makes the pool reconnect.
ClientWritecan be caused by a slow consumer even when the database host network looks idle.- Replication-flavoured Client waits belong to the same protocol boundary but have different operational owners.
Waiting to read data from the client
Waiting to write data to the client
Waiting to read data from the client while establishing a GSSAPI session
Waiting in WAL receiver to establish connection to remote server
Waiting in WAL receiver to receive data from remote server
Waiting for SSL while attempting connection
Waiting for WAL to be received and flushed by the physical standby
Waiting for WAL to be flushed in WAL sender process
Waiting for any activity when processing replies from WAL receiver in WAL sender process