# Client: ClientWrite

> Waiting to write data to the client
---

<div class="event-kicker">PostgreSQL wait event dossier</div>
<div class="event-identity">
  <span>Class<strong>Client</strong></span>
  <span>Event<strong><code>ClientWrite</code></strong></span>
  <span>Versions<strong>PG 13-18</strong></span>
  <span>Evidence<strong>2 source location(s)</strong></span>
</div>

## Official description {#official-description}

Waiting to write data to the client

| PG 13 | PG 14 | PG 15 | PG 16 | PG 17 | PG 18 |
| :---: | :---: | :---: | :---: | :---: | :---: |
| ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |

## Trigger mechanism {#mechanism}

`WAIT_EVENT_CLIENT_WRITE` at `src/backend/libpq/be-secure.c:344` is the grep-verified reporting path. The public identity/resource is mapped at `src/backend/utils/activity/wait_event_names.txt:86`. The instrumented operation is: Waiting to write data to the client. The frontend protocol path reports ClientWrite immediately before a socket, TLS/GSS, or replication-client operation blocks. PostgreSQL is waiting for the remote side or network to progress.

## Normal or trouble? {#normal-vs-trouble}

- <span class="severity-normal">**Normal:**</span> Idle ClientRead sessions are normal connection-pool inventory.
- <span class="severity-watch">**Investigate:**</span> Investigate active writes, handshakes, old idle-in-transaction sessions, connection exhaustion, or replication-client stalls.

## Diagnostic SQL {#diagnostic-sql}

```sql {title="Sessions waiting on Client/ClientWrite"}
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'Client'
  AND wait_event = 'ClientWrite'
ORDER BY query_age DESC NULLS LAST;
```

```sql {title="Current Client cohort"}
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'Client'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
```

```sql {title="Lock and relation context for these sessions"}
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'Client'
  AND a.wait_event = 'ClientWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;
```

## Response {#response}

1. Check state and transaction age before counting the wait as load.
2. Correlate with the owning application, pool, and network path.
3. Fix consumer backpressure or pool policy rather than repeatedly terminating connections.

## Source evidence {#source}

- [PostgreSQL 18.6 · src/backend/libpq/be-secure.c:344](https://github.com/postgres/postgres/blob/REL_18_6/src/backend/libpq/be-secure.c#L344) — `WAIT_EVENT_CLIENT_WRITE`
- [PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:86](https://github.com/postgres/postgres/blob/REL_18_6/src/backend/utils/activity/wait_event_names.txt#L86) — `CLIENT_WRITE`

## Related controls and signals {#related}

- **GUCs:** [[guc:max_connections]](/guc/max-connections/) · [[guc:idle_in_transaction_session_timeout]](/guc/idle-in-transaction-session-timeout/)
- **Metrics:** [[metric:waiting_sessions]](/metric/waiting-sessions/) · [[metric:wait_event_share]](/metric/wait-event-share/) · [[metric:active_backends]](/metric/active-backends/)

---

Backlinks:

- [Client](/client/)