Incident brief
Query canceled
A statement ran longer than the configured statement_timeout, and PostgreSQL canceled it. This is PostgreSQL enforcing a time limit you set, not a crash.
In 10 seconds
- What
- Query canceled
- What triggers it
- SET statement_timeout to a short value, such as 500ms.
- The fix
- Raise statement_timeout for this specific query if it's genuinely expected to take longer.
- Proof
- Reproduced on PostgreSQL 16.14 → A 2-second query, run under a 500ms statement_timeout, was canceled with SQLSTATE 57014. The session was unaffected afterward.
The fix
What to do right now
The immediate, application-level response to this error.
- Raise statement_timeout for this specific query if it's genuinely expected to take longer.
- If the query is meant to be fast, treat the timeout as a signal to investigate the query, not just to retry it — see the counterexample.
- Retrying the exact same slow query with the exact same timeout will simply time out again.
SET statement_timeout = '3s';
SELECT pg_sleep(2);
RESET statement_timeout;Diagnose
See it live on the server
Run these against the affected instance to confirm the diagnosis before you act.
Standard triage — not specific to this error
These are canonical PostgreSQL system-catalog queries, shown as SQL to run. No sample output is attached because this is general triage, not a captured lab transcript.This SQLSTATE does not have an error-specific live snapshot yet. These are the canonical system-catalog queries you run against the affected server to see the problem in real time — standard triage, not a reproduced transcript.
What is running right now
Active backends, how long each has been running, and what it is waiting on.
SELECT pid,
state,
wait_event_type,
wait_event,
now() - query_start AS running_for,
left(query, 80) AS query
FROM pg_stat_activity
WHERE state <> 'idle'
AND pid <> pg_backend_pid()
ORDER BY running_for DESC NULLS LAST;Who is blocking whom
Turn raw blocking PIDs into the actual queries on both sides of the wait.
SELECT blocked.pid AS blocked_pid,
blocked.query AS blocked_query,
blocking.pid AS blocking_pid,
blocking.query AS blocking_query
FROM pg_stat_activity AS blocked
JOIN LATERAL unnest(pg_blocking_pids(blocked.pid)) AS b(pid) ON true
JOIN pg_stat_activity AS blocking ON blocking.pid = b.pid
WHERE cardinality(pg_blocking_pids(blocked.pid)) > 0;Locks that are still waiting
Every lock a backend has requested but not yet been granted.
SELECT l.pid,
l.locktype,
l.mode,
l.granted,
COALESCE(c.relname, l.transactionid::text) AS object
FROM pg_locks l
LEFT JOIN pg_class c ON c.oid = l.relation
WHERE NOT l.granted
ORDER BY l.pid;Why it happens
What PostgreSQL is telling you
The mechanism behind the error, grounded in the official manual — not paraphrased.
PostgreSQL 16 Documentation — Client Connection Defaults (statement_timeout)
Abort any statement that takes more than the specified amount of time. ... A value of zero (the default) disables the timeout.Read the full section on postgresql.org →
The canceled query
statement_timeout was set to 500ms, and pg_sleep(2) takes 2000ms. Per the manual, PostgreSQL aborts any statement that runs longer than the configured limit, so it canceled the query partway through.Confirming the session still works
The canceled query didn't affect the session — the next statement ran normally.Reproduce & verify
A real, single-session PostgreSQL reproduction
A literal transcript of SQL run against a live PostgreSQL instance in an isolated lab — the commands below are exactly what was executed.
- 1SET statement_timeout to a short value, such as 500ms.
- 2Run a query that takes longer than that, such as SELECT pg_sleep(2).
- 3SQLSTATE 57014 is reported; the statement is aborted.
One client: lower statement_timeout, then run a query that deliberately takes longer than that.
-- No table needed: pg_sleep stands in for any statement that runs too long.
SELECT 'no schema required' AS setup_note;SET statement_timeout = '500ms';
SELECT pg_sleep(2);
RESET statement_timeout;SELECT 1 AS session_still_alive;What PostgreSQL actually returned
setup_note
--------------------
no schema required
(1 row)SET
ERROR: canceling statement due to statement timeout
RESET session_still_alive
----------------------
1
(1 row)Raising statement_timeout for this one query, instead of leaving it at the same restrictive value, was tested directly against the identical slow query.
Set a longer statement_timeout that comfortably covers the query's real running time, then run the same query again.
Without this
Above: the query is canceled under a 500ms timeout.
With this, tested
Below: the same query, under a 3s timeout, completes normally.
What Pro unlocks here
- The exact prevention SQL — copy-paste ready
- Raw psql output captured from the Docker lab
- A senior-DBA action list to take it further
- Live monitoring queries to catch it in production
- The deeper audit: fix-that-fails counterexample, GUC before/after, server-log evidence
Related & next steps
Follow the thread
Everything this error touches — jump straight to the sibling error, term, runbook, or parameter.
Related errors
Verification
- Last verified
- 2026-07-16 (Docker lab, PostgreSQL 16.14)
- Reviewed by
- Verified against PostgreSQL 16.14 in an isolated lab environment
- Audit status
- reviewed