Client waits

• 1: Client: ClientRead
• 2: Client: ClientWrite
• 3: Client: GssOpenServer
• 4: Client: LibpqwalreceiverConnect
• 5: Client: LibpqwalreceiverReceive
• 6: Client: SslOpenServer
• 7: Client: WaitForStandbyConfirmation
• 8: Client: WalSenderWaitForWal
• 9: Client: WalSenderWriteData

1 - Client: ClientRead

Official description

Waiting to read data from the client

Trigger mechanism

WAIT_EVENT_CLIENT_READ at src/backend/libpq/be-secure.c:219 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:85. The instrumented operation is: Waiting to read data from the client. The frontend protocol path reports ClientRead 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: Idle ClientRead sessions are normal connection-pool inventory.
• Investigate: Investigate active writes, handshakes, old idle-in-transaction sessions, connection exhaustion, or replication-client stalls.

Diagnostic SQL

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 = 'ClientRead'
ORDER BY query_age DESC NULLS LAST;

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;

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 = 'ClientRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

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

• PostgreSQL 18.6 · src/backend/libpq/be-secure.c:219 — WAIT_EVENT_CLIENT_READ
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:85 — CLIENT_READ

Related controls and signals

• GUCs: [guc:max_connections] · [guc:idle_in_transaction_session_timeout]
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share] · [metric:active_backends]

2 - Client: ClientWrite

Official description

Waiting to write data to the client

Trigger 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: Idle ClientRead sessions are normal connection-pool inventory.
• Investigate: Investigate active writes, handshakes, old idle-in-transaction sessions, connection exhaustion, or replication-client stalls.

Diagnostic SQL

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;

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;

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

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

• PostgreSQL 18.6 · src/backend/libpq/be-secure.c:344 — WAIT_EVENT_CLIENT_WRITE
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:86 — CLIENT_WRITE

Related controls and signals

• GUCs: [guc:max_connections] · [guc:idle_in_transaction_session_timeout]
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share] · [metric:active_backends]

3 - Client: GssOpenServer

Official description

Waiting to read data from the client while establishing a GSSAPI session

Earlier names: Client/GSSOpenServer (PG 13-16)

Trigger mechanism

WAIT_EVENT_GSS_OPEN_SERVER at src/backend/libpq/be-secure-gssapi.c:461 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:277. The instrumented operation is: Waiting to read data from the client while establishing a GSSAPI session. The frontend protocol path reports GssOpenServer 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: Idle ClientRead sessions are normal connection-pool inventory.
• Investigate: Investigate active writes, handshakes, old idle-in-transaction sessions, connection exhaustion, or replication-client stalls.

Diagnostic SQL

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 = 'GssOpenServer'
ORDER BY query_age DESC NULLS LAST;

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;

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 = 'GssOpenServer'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

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

• PostgreSQL 16.15 · src/backend/libpq/be-secure-gssapi.c:461 — WAIT_EVENT_GSS_OPEN_SERVER
• PostgreSQL 16.15 · src/backend/utils/activity/wait_event.c:277 — GSSOpenServer
• PostgreSQL 18.6 · src/backend/libpq/be-secure-gssapi.c:462 — WAIT_EVENT_GSS_OPEN_SERVER
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:87 — GSS_OPEN_SERVER

Related controls and signals

• GUCs: [guc:max_connections] · [guc:idle_in_transaction_session_timeout]
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share] · [metric:active_backends]

4 - Client: LibpqwalreceiverConnect

Official description

Waiting in WAL receiver to establish connection to remote server

Earlier names: Client/LibPQWalReceiverConnect (PG 13-16)

Trigger mechanism

WAIT_EVENT_LIBPQWALRECEIVER_CONNECT at src/backend/replication/libpqwalreceiver/libpqwalreceiver.c:231 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:280. The instrumented operation is: Waiting in WAL receiver to establish connection to remote server. The frontend protocol path reports LibpqwalreceiverConnect 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: Idle ClientRead sessions are normal connection-pool inventory.
• Investigate: Investigate active writes, handshakes, old idle-in-transaction sessions, connection exhaustion, or replication-client stalls.

Diagnostic SQL

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 = 'LibpqwalreceiverConnect'
ORDER BY query_age DESC NULLS LAST;

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;

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 = 'LibpqwalreceiverConnect'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

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

• PostgreSQL 16.15 · src/backend/replication/libpqwalreceiver/libpqwalreceiver.c:231 — WAIT_EVENT_LIBPQWALRECEIVER_CONNECT
• PostgreSQL 16.15 · src/backend/utils/activity/wait_event.c:280 — LibPQWalReceiverConnect
• PostgreSQL 18.6 · src/backend/replication/libpqwalreceiver/libpqwalreceiver.c:228 — WAIT_EVENT_LIBPQWALRECEIVER_CONNECT
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:88 — LIBPQWALRECEIVER_CONNECT

Related controls and signals

• GUCs: [guc:wal_buffers] · [guc:synchronous_commit] · [guc:max_connections] · [guc:idle_in_transaction_session_timeout]
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share] · [metric:wal_bytes] · [metric:wal_write_time] · [metric:active_backends]

5 - Client: LibpqwalreceiverReceive

Official description

Waiting in WAL receiver to receive data from remote server

Earlier names: Client/LibPQWalReceiverReceive (PG 13-16)

Trigger mechanism

WAIT_EVENT_LIBPQWALRECEIVER_RECEIVE at src/backend/replication/libpqwalreceiver/libpqwalreceiver.c:876 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:283. The instrumented operation is: Waiting in WAL receiver to receive data from remote server. The frontend protocol path reports LibpqwalreceiverReceive 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: Idle ClientRead sessions are normal connection-pool inventory.
• Investigate: Investigate active writes, handshakes, old idle-in-transaction sessions, connection exhaustion, or replication-client stalls.

Diagnostic SQL

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 = 'LibpqwalreceiverReceive'
ORDER BY query_age DESC NULLS LAST;

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;

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 = 'LibpqwalreceiverReceive'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

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

• PostgreSQL 16.15 · src/backend/replication/libpqwalreceiver/libpqwalreceiver.c:876 — WAIT_EVENT_LIBPQWALRECEIVER_RECEIVE
• PostgreSQL 16.15 · src/backend/utils/activity/wait_event.c:283 — LibPQWalReceiverReceive
• PostgreSQL 18.6 · src/backend/replication/libpqwalreceiver/libpqwalreceiver.c:258 — WAIT_EVENT_LIBPQWALRECEIVER_RECEIVE
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:89 — LIBPQWALRECEIVER_RECEIVE

Related controls and signals

• GUCs: [guc:wal_buffers] · [guc:synchronous_commit] · [guc:max_connections] · [guc:idle_in_transaction_session_timeout]
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share] · [metric:wal_bytes] · [metric:wal_write_time] · [metric:active_backends]

6 - Client: SslOpenServer

Official description

Waiting for SSL while attempting connection

Earlier names: Client/SSLOpenServer (PG 13-16)

Trigger mechanism

WAIT_EVENT_SSL_OPEN_SERVER at src/backend/libpq/be-secure-openssl.c:508 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:286. The instrumented operation is: Waiting for SSL while attempting connection. The frontend protocol path reports SslOpenServer 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: Idle ClientRead sessions are normal connection-pool inventory.
• Investigate: Investigate active writes, handshakes, old idle-in-transaction sessions, connection exhaustion, or replication-client stalls.

Diagnostic SQL

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 = 'SslOpenServer'
ORDER BY query_age DESC NULLS LAST;

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;

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 = 'SslOpenServer'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

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

• PostgreSQL 16.15 · src/backend/libpq/be-secure-openssl.c:508 — WAIT_EVENT_SSL_OPEN_SERVER
• PostgreSQL 16.15 · src/backend/utils/activity/wait_event.c:286 — SSLOpenServer
• PostgreSQL 18.6 · src/backend/libpq/be-secure-openssl.c:526 — WAIT_EVENT_SSL_OPEN_SERVER
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:90 — SSL_OPEN_SERVER

Related controls and signals

• GUCs: [guc:max_connections] · [guc:idle_in_transaction_session_timeout]
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share] · [metric:active_backends]

7 - Client: WaitForStandbyConfirmation

Official description

Waiting for WAL to be received and flushed by the physical standby

Trigger mechanism

WAIT_EVENT_WAIT_FOR_STANDBY_CONFIRMATION at src/backend/replication/slot.c:3083 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:91. The instrumented operation is: Waiting for WAL to be received and flushed by the physical standby. The frontend protocol path reports WaitForStandbyConfirmation 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: Idle ClientRead sessions are normal connection-pool inventory.
• Investigate: Investigate active writes, handshakes, old idle-in-transaction sessions, connection exhaustion, or replication-client stalls.

Diagnostic SQL

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 = 'WaitForStandbyConfirmation'
ORDER BY query_age DESC NULLS LAST;

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;

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 = 'WaitForStandbyConfirmation'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

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

• PostgreSQL 18.6 · src/backend/replication/slot.c:3083 — WAIT_EVENT_WAIT_FOR_STANDBY_CONFIRMATION
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:91 — WAIT_FOR_STANDBY_CONFIRMATION

Related controls and signals

• GUCs: [guc:max_connections] · [guc:idle_in_transaction_session_timeout]
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share] · [metric:active_backends]

8 - Client: WalSenderWaitForWal

Official description

Waiting for WAL to be flushed in WAL sender process

Earlier names: Client/WalSenderWaitForWAL (PG 13-16)

Trigger mechanism

WAIT_EVENT_WAL_SENDER_WAIT_WAL at src/backend/replication/walsender.c:1714 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:289. The instrumented operation is: Waiting for WAL to be flushed in WAL sender process. The frontend protocol path reports WalSenderWaitForWal 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: Idle ClientRead sessions are normal connection-pool inventory.
• Investigate: Investigate active writes, handshakes, old idle-in-transaction sessions, connection exhaustion, or replication-client stalls.

Diagnostic SQL

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 = 'WalSenderWaitForWal'
ORDER BY query_age DESC NULLS LAST;

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;

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 = 'WalSenderWaitForWal'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

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

• PostgreSQL 16.15 · src/backend/replication/walsender.c:1714 — WAIT_EVENT_WAL_SENDER_WAIT_WAL
• PostgreSQL 16.15 · src/backend/utils/activity/wait_event.c:289 — WalSenderWaitForWAL
• PostgreSQL 18.6 · src/backend/replication/walsender.c:1813 — WAIT_EVENT_WAL_SENDER_WAIT_FOR_WAL
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:92 — WAL_SENDER_WAIT_FOR_WAL

Related controls and signals

• GUCs: [guc:wal_buffers] · [guc:synchronous_commit] · [guc:max_connections] · [guc:idle_in_transaction_session_timeout]
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share] · [metric:wal_bytes] · [metric:wal_write_time] · [metric:active_backends]

9 - Client: WalSenderWriteData

Official description

Waiting for any activity when processing replies from WAL receiver in WAL sender process

Trigger mechanism

WAIT_EVENT_WAL_SENDER_WRITE_DATA at src/backend/replication/walsender.c:1653 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:93. The instrumented operation is: Waiting for any activity when processing replies from WAL receiver in WAL sender process. The frontend protocol path reports WalSenderWriteData 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: Idle ClientRead sessions are normal connection-pool inventory.
• Investigate: Investigate active writes, handshakes, old idle-in-transaction sessions, connection exhaustion, or replication-client stalls.

Diagnostic SQL

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 = 'WalSenderWriteData'
ORDER BY query_age DESC NULLS LAST;

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;

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 = 'WalSenderWriteData'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

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

• PostgreSQL 18.6 · src/backend/replication/walsender.c:1653 — WAIT_EVENT_WAL_SENDER_WRITE_DATA
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:93 — WAL_SENDER_WRITE_DATA

Related controls and signals

• GUCs: [guc:wal_buffers] · [guc:synchronous_commit] · [guc:max_connections] · [guc:idle_in_transaction_session_timeout]
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share] · [metric:wal_bytes] · [metric:wal_write_time] · [metric:active_backends]