57014ERRORTier 2 — Caution✅ HIGH confidence

canceling statement due to statement timeout

Category: Operator InterventionVersions: All Postgres versions

What this means

The statement exceeded the statement_timeout threshold set for the session or role and Postgres cancelled it. The transaction remains open but the statement is rolled back; a ROLLBACK is required before new statements can run in the same transaction block.

Why it happens

1A slow query (full table scan, missing index, heavy join) exceeded the configured statement_timeout
2statement_timeout is set too aggressively for the workload (e.g. 100ms for a reporting query)
3Lock wait caused the statement to take longer than the timeout (lock wait counts toward statement_timeout)
4Autovacuum or heavy write activity slowed down the query

How to reproduce

A session has statement_timeout set and a slow query exceeds it.

trigger — this will ERROR

SET statement_timeout = '100ms';

-- A query that takes longer than 100ms:
SELECT pg_sleep(1); -- triggers 57014

ERROR: canceling statement due to statement timeout

Fix 1: Add an index to make the query fast enough

When the query is legitimately slow due to a missing index.

fix

-- Find the slow query plan:
EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM orders WHERE customer_id = 42;

-- Add missing index:
CREATE INDEX CONCURRENTLY idx_orders_customer_id ON orders (customer_id);

Why this works

A sequential scan on a large table touches every heap page, taking O(n) I/O. An index lookup is O(log n) plus a small number of heap fetches. By adding an appropriate index the executor chooses an index scan, reducing wall time well below the timeout threshold.

Fix 2: Increase statement_timeout for specific operations

When the query is genuinely long-running by design (reporting, bulk export) and the timeout is too short.

fix

-- Increase for this session only:
SET statement_timeout = '30s';
SELECT * FROM large_report_view;

-- Or set per role:
ALTER ROLE reporter SET statement_timeout = '5min';

Why this works

statement_timeout is checked by the query executor at each tuple fetch and at lock acquisition points. Setting a larger value raises the threshold for the affected session or role without affecting other connections.

What not to do

✗

Set statement_timeout = 0 (disabled) globally to stop the errors

Why it's wrong: Removes the safety net against runaway queries; a single bad query can monopolise the database for hours.

Sources

📚 Official docs: https://www.postgresql.org/docs/current/errcodes-appendix.html

📚 Feature docs: https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-STATEMENT-TIMEOUT

🔧 Source ref: src/backend/tcop/postgres.c — ProcessInterrupts()

📖 Further reading: Client Configuration — Timeouts

Confidence assessment

✅ HIGH confidence

Stable and well-documented. statement_timeout behaviour is consistent. Edge case: statement_timeout does not apply to commands executed inside PL/pgSQL procedures called from the query; each statement within the procedure is timed individually.