Interpreting pg_stat_activity Wait Events for Pool Issues

This guide is part of PostgreSQL Server-Side Connection Diagnostics. Client-side pool metrics tell you that connections are all checked out. They cannot tell you why the connections are not coming back. Wait events answer that: for every backend, PostgreSQL publishes what it is currently blocked on, and a handful of those events point straight back at pool configuration.

The critical distinction to hold onto is that a backend can be busy in three completely different ways, and only one of them means the database is the bottleneck:

• Doing work. wait_event_type IS NULL — the backend is on CPU or in a syscall that PostgreSQL does not instrument. This is real database work.
• Waiting on something inside PostgreSQL. Lock, LWLock, IO, BufferPin — genuine database contention.
• Waiting on your application. Client: ClientRead — the backend has nothing to do and is waiting for the client to send the next command.

That last one is the pool diagnosis hiding in plain sight. A hundred backends in state = 'idle in transaction' with wait_event = 'ClientRead' is not a database problem at all. It is an application holding transactions open across network calls, and no amount of database tuning will help.

The query to start from

SELECT state,
       wait_event_type,
       wait_event,
       count(*)                                   AS backends,
       max(now() - state_change)::interval(0)     AS longest_in_state,
       max(now() - xact_start)::interval(0)       AS longest_xact
FROM pg_stat_activity
WHERE backend_type = 'client backend'
  AND pid <> pg_backend_pid()
GROUP BY 1, 2, 3
ORDER BY backends DESC;

Grouping before you look at individual rows is deliberate. A single long-running query is a query problem; two hundred backends sharing one wait event is a systemic problem, and only the grouped view makes the difference obvious. backend_type = 'client backend' filters out autovacuum workers, the walwriter and background workers, which otherwise pad the counts with events that have nothing to do with your pool.

The events that matter for pooling

The pattern to internalise is that only the first row calls for an application-side fix to how connections are borrowed, while several of the others actively argue against enlarging the pool. LWLock: BufferMapping and LWLock: WALWrite dominating the distribution means the instance is already past its useful concurrency; adding connections increases queueing at the same serialisation point and raises tail latency without raising throughput. That relationship is the empirical basis for the sizing formulas in Connection Pool Sizing Formulas.

Finding the transactions that hold connections open

The single highest-value query for pool problems isolates backends that are inside a transaction but not executing anything:

SELECT pid,
       application_name,
       client_addr,
       now() - xact_start      AS xact_age,
       now() - state_change    AS idle_for,
       wait_event_type,
       wait_event,
       left(query, 120)        AS last_statement
FROM pg_stat_activity
WHERE state = 'idle in transaction'
  AND now() - state_change > interval '5 seconds'
ORDER BY xact_age DESC;

The query column here is the last statement executed, not a running one — that is exactly what you want, because it names the statement after which the application went away to do something else. Common culprits it reveals: a transaction opened before an HTTP call to a payment provider, an ORM session left open across a template render, a batch job that begins a transaction and then reads a file.

Each such backend is a pooled connection that is unavailable to anyone else, and it is also holding its snapshot, which prevents vacuum from cleaning up dead tuples. Two problems for the price of one.

Set idle_in_transaction_session_timeout so these cannot accumulate indefinitely:

ALTER DATABASE orders SET idle_in_transaction_session_timeout = '30s';

That converts a silent connection leak into a visible, attributable error — FATAL: terminating connection due to idle-in-transaction timeout — with the application name and address in the log. It is one of the highest-value single settings on a pooled PostgreSQL instance.

Correlating with the client-side pool

Wait events are only half the picture. The diagnosis comes from putting the server-side distribution next to the client-side pool state at the same moment:

The third row deserves emphasis because it is the classic leak signature: the pool believes every connection is checked out, but the server shows those same connections sitting idle with no transaction open. That combination means application code borrowed connections and never returned them. On the JVM the borrow site is recoverable directly — see configuring the HikariCP leak detection threshold.

The fourth row is the network case: fewer server backends than the pool believes it holds means connections died without the pool noticing, which is what connection age caps exist to prevent.

Common failure patterns and remediation

Sampling rather than snapshotting

pg_stat_activity is a snapshot. A single query catches whatever was happening in that instant, which is close to useless for intermittent problems. Sample it on an interval and aggregate:

CREATE TABLE IF NOT EXISTS wait_samples (
  sampled_at      timestamptz NOT NULL DEFAULT now(),
  state           text,
  wait_event_type text,
  wait_event      text,
  backends        int
);

INSERT INTO wait_samples (state, wait_event_type, wait_event, backends)
SELECT state, wait_event_type, wait_event, count(*)
FROM pg_stat_activity
WHERE backend_type = 'client backend'
GROUP BY 1, 2, 3;

Run that every few seconds from a scheduler and you have a poor man’s wait-event profiler. Aggregating over a window then tells you what the instance was mostly doing during an incident rather than what it happened to be doing at one moment:

SELECT wait_event_type, wait_event, sum(backends) AS backend_seconds
FROM wait_samples
WHERE sampled_at BETWEEN '2026-07-24 09:00' AND '2026-07-24 09:30'
GROUP BY 1, 2
ORDER BY backend_seconds DESC
LIMIT 15;

If the pg_wait_sampling extension is available on your instance, use it instead — it does the same sampling in shared memory at far lower cost and with much higher resolution. On managed databases where extensions are restricted, the table-based approach above is the practical fallback, and Performance Insights on RDS and Aurora exposes the same data through its own interface.

Operational boundary

Wait events describe what backends are blocked on right now. They do not attribute a wait to a query plan, they do not survive a connection closing, and they cannot see time spent in your application between statements — only that the backend was waiting for you. For anything that needs statement-level attribution, pg_stat_statements is the right tool and answers a different question.

They also say nothing about connections that never reached PostgreSQL. If your pool cannot get a connection because the proxy in front of the database is out of server slots, pg_stat_activity will look perfectly healthy. Check the proxy’s own statistics first in that topology, as described in PgBouncer Metrics Monitoring.

Frequently Asked Questions

Related

• PostgreSQL Server-Side Connection Diagnostics — the parent guide on reading backend state.
• Tuning PostgreSQL max_connections and superuser_reserved_connections — setting the ceiling these backends live inside.
• Detecting Connection Pool Saturation — the client-side half of the same diagnosis.
• Connection Pool Sizing Formulas — why lock and buffer contention argue for a smaller pool.
• Configuring the HikariCP Leak Detection Threshold — recovering the borrow site behind a leak signature.