SQLSTATE 57014 — query_canceled: Statement Timeout Exceeded

SQLSTATE 57014 condition query_canceled class 57 — 57 — Operator Intervention severity ERROR
Reproduced & verified on PostgreSQL 14.23, 15.18, 16.14, 17.10 and 18.4 — identical message on every version.
Last reviewed 28 May 2026 · Reproduced live with the SQL on this page.

! Symptoms Free

Conditions:

  • Application log: ERROR: canceling statement due to statement timeout
  • PostgreSQL log: LOG: statement canceled due to statement timeout
  • Global statement_timeout is set and a specific role/query needs longer execution
  • Nightly batch jobs or reports consistently hit the timeout

1 Environment & reproduce Free

Difficulty: Intermediate  |  PostgreSQL versions: 12, 13, 14, 15, 16, 17

? Root cause Free

  • statement_timeout applies to each individual statement, not the entire transaction. A transaction with 5 queries each under the limit is fine.
  • lock_timeout and statement_timeout are independent — a query can be killed by either.
  • Setting statement_timeout = 0 per role disables it for that role — use carefully.
  • SET LOCAL statement_timeout = '2h' inside a transaction block applies only to that transaction.
  • PgBouncer passes through PostgreSQL timeouts — they are not a PgBouncer setting.
  • idle_session_timeout (PG14+) terminates sessions that are fully idle — different from statement_timeout.

Keep a strict global statement_timeout for OLTP. Grant reporting roles a higher or zero timeout via ALTER ROLE. For scheduled jobs, set timeout at the session level at the start of the connection.

2 Diagnose Free

RESULT
-- Check current timeout settings:
SELECT name, setting, unit, source
FROM pg_settings
WHERE name IN ('statement_timeout','lock_timeout','idle_in_transaction_session_timeout')
ORDER BY name;

-- Find queries that historically timed out (if auto_explain or pg_stat_statements):
SELECT left(query,80) AS query, calls,
    round(max_exec_time::numeric/1000, 1) AS max_sec,
    round(mean_exec_time::numeric/1000, 1) AS avg_sec
FROM pg_stat_statements
WHERE max_exec_time > 1800000  -- queries that ran > 30 minutes before being killed
ORDER BY max_exec_time DESC LIMIT 10;

🔒 Diagnose deeper Pro

🔒

Find every latent occurrence before it ships

The steps above clear this incident. Pro adds the executed, verified depth that stops the whole class of bug across your fleet.

  • ✓Catalog & log queries that surface every at-risk object before a migration ships.
  • ✓Inspect-without-running tricks (\gdesc and friends).
  • ✓Exactly where the log line surfaces on RDS, Azure & Cloud SQL.
  • ✓Cross-version gotchas, verified on PostgreSQL 14–18.
Unlock Pro from $24.99/mo · or $199/yr — unlocks every Pro section.

Every Pro query on this site is executed against real PostgreSQL and verified — we never publish an untested snippet.

3 Recovery & verify Free

Keep a strict global statement_timeout for OLTP. Grant reporting roles a higher or zero timeout via ALTER ROLE. For scheduled jobs, set timeout at the session level at the start of the connection.