SQLSTATE 57014 ERROR Class 57: Operator Intervention

query_canceled canceling statement due to statement timeout — 57014

PostgreSQL error "canceling statement due to statement timeout" (SQLSTATE 57014): what it means, common causes, and how to fix it.

PG 12, 13, 14, 15, 16, 17, 18 Official docs
Last reviewed May 2025 Grounded in source

Diagnostic Queries

Symptoms

A statement ran longer than the statement_timeout setting and PostgreSQL canceled it. The query was interrupted mid-execution and rolled back; no partial result is returned.

  • The statement is canceled with SQLSTATE 57014.
  • Repeatable for slow queries; intermittent when caused by lock waits.
  • Often a too-aggressive timeout applied to a reporting/analytical query.

What the server log shows

ERROR:  canceling statement due to statement timeout
STATEMENT:  SELECT * FROM big_table ORDER BY created_at;

Why PostgreSQL raises this — what the manual says

Section 19.11.1 Statement Behavior (statement_timeout):

“Abort any statement that takes more than the specified amount of time.”

A per-statement timer starts when execution begins. If it expires before the statement finishes, the backend cancels the running query and reports 57014. The setting can be applied globally, per role, per database, or per session.

Common causes

  • A genuinely slow query (missing index, huge scan, bad plan).
  • statement_timeout set too aggressively for the workload.
  • Lock waits counting against the statement clock.
  • A reporting query running under an OLTP-tuned timeout.

Relevant GUC parameters

Parameter Default Effect
statement_timeout 0 (disabled) Max time a single statement may run before it is canceled. Set per role/session to separate OLTP from reporting.
lock_timeout 0 (disabled) Caps time spent waiting for a lock specifically, so lock waits don’t consume the whole statement budget.

How to fix it

  1. Optimize the query — inspect EXPLAIN (ANALYZE, BUFFERS) and add indexes.
  2. Raise the timeout for the specific session: SET statement_timeout = '60s';.
  3. Set per-role limits so OLTP and reporting differ: ALTER ROLE reports SET statement_timeout = '5min';.
  4. Break very large operations into batches.

Diagnostic query

-- Current effective timeout
SHOW statement_timeout;

Check session, role, and database scopes — the most specific wins.

Related & next steps

Reference: PostgreSQL 18 Section 19.11 “Client Connection Defaults”.

Was this helpful?