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.
What lands in your log
ERROR: canceling statement due to statement timeout
In 10 seconds
- What triggers it
- SET statement_timeout to a short value, such as 500ms.
- 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.
Fix
What to do right now
Application-level steps for 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;For this error
See this error live on the server
Run these against the affected instance to confirm the diagnosis before you act.
Determine whether PostgreSQL canceled the statement because of statement_timeout, lock_timeout, recovery conflict, or an explicit pg_cancel_backend call.
Timeouts that can cancel this session
Read the effective timeout values before increasing any of them.
SELECT current_setting('statement_timeout') AS statement_timeout,
current_setting('lock_timeout') AS lock_timeout,
current_setting('idle_in_transaction_session_timeout') AS idle_in_transaction_timeout;Long or waiting statements now
Find current statements that are close to the same timeout/wait condition.
SELECT pid, application_name, wait_event_type, wait_event,
now() - query_start AS running_for, left(query, 120) AS query
FROM pg_stat_activity
WHERE state = 'active' AND pid <> pg_backend_pid()
ORDER BY query_start;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.
Without this
Above: the query is canceled under a 500ms timeout.
With this, tested
Below: the same query, under a 3s timeout, completes normally.
- A second operational test: exact SQL, raw output, measured result, and engineer notes
- Fix that retries without actually fixing anything: exact SQL, output, and verdict
- A manual-grounded production interpretation of the lab result
Card required. Cancel before day 7 and you are not charged.
Runbook to fix this
Runbooks for this incident
Full step-by-step fixes for the condition behind this error: the diagnosis, the exact SQL, and output captured in the lab.
- Capture Sev-1 evidence before recovery erases itEvery postmortem ends at 'high load' because the evidence was gone by morning.Free
- Detect and resolve lock contentionQueries hang with no error and no progress, and you need the wait graph now.Free
- Find your slowest queries with pg_stat_statementsEverything feels slow and you are guessing which query deserves the blame.Free
Connected
Everything this error touches
Every page this SQLSTATE connects to: the concept that explains it, the runbooks that fix it, the parameters you tune to prevent it, and the sibling errors it travels with. All real cross-references. Jump straight in, or open the full interactive map.
Fix it — runbooks
Set sane statement, lock, and idle timeoutsDetect and resolve lock contentionCapture Sev-1 evidence before recovery erases itKnow which lock mode your statement takesFind what is actually burning CPUReplace deep OFFSET paging with keyset paginationRight-size work_mem for hash aggregatesStop disk-spilled sorts by tuning work_memWhat happens when your synchronous standby diesWhy your query ignores the index, and how to fix itCap parallel workers that multiply CPU and memoryFind your slowest queries with pg_stat_statementsRead the loops multiplier in EXPLAIN ANALYZESlow query from a sequential scan on a large tableSpeed up COUNT(*) on a large tableTame a lossy bitmap heap scanTune to prevent it
Related errors
Verification
- Last verified
- 2026-07-16 (Docker lab, PostgreSQL 16.14)
- Verification scope
- Verified against PostgreSQL 16.14 in an isolated lab environment
- Audit status
- reviewed
Went further?
Pro unlocks the second lab proof
Free page stops the bleeding. Pro adds the operational test, SQLSTATE audit, and deeper evidence, same error, more certainty.