PostgreSQL Error 57014

SQLSTATE

57014

Condition name

query_canceled

Product

PostgreSQL

Versions

PostgreSQL 13 to 18

Category

Transactions & Concurrency

Last reviewed

24 October 2026

What it means

SQLSTATE 57014 means the running statement was cancelled, either because it exceeded statement_timeout or because a cancel request arrived from the client or another session.

statement_timeout aborts any statement that runs longer than the set time; zero, the default, disables it. The timer runs from the moment the command reaches the server until the server completes it, and applies to each statement separately. When it expires, the statement fails with canceling statement due to statement timeout. A cancel request has the same effect with a different message, canceling statement due to user request: it comes from pg_cancel_backend(pid) in another session, from Ctrl+C in psql, or from a driver whose own query timeout sends a cancel to the server.

Only the statement is cancelled; the session stays connected. Inside a transaction block the whole transaction is aborted, so later statements fail with 25P02 until you ROLLBACK. Two related settings raise other SQLSTATEs: lock_timeout (55P03, waiting too long for a lock) and transaction_timeout or idle_in_transaction_session_timeout, which end the whole session.

Common causes

• statement_timeout is set for the role, the database, the connection string or the application, and a slow query exceeds it.
• A query became slow: a missing index, outdated statistics, more data than before, or a plan that changed.
• The statement waited a long time for a lock held by another transaction; the wait counts towards statement_timeout.
• A driver or ORM query timeout (for example a JDBC setQueryTimeout) expired and the driver sent a cancel request.
• Someone pressed Ctrl+C in psql or a monitoring script ran pg_cancel_backend on the session.

Diagnose it

Read-only These queries only read the system catalogs (pg_catalog, information_schema) and statistics views such as pg_stat_activity and pg_locks. They do not change data, roles or settings, so they are safe to run first.

SELECT name, setting, unit, source
FROM pg_settings
WHERE name IN ('statement_timeout', 'lock_timeout',
               'idle_in_transaction_session_timeout', 'transaction_timeout');

SELECT r.rolname, d.datname, s.setconfig
FROM pg_db_role_setting AS s
LEFT JOIN pg_roles AS r ON r.oid = s.setrole
LEFT JOIN pg_database AS d ON d.oid = s.setdatabase
ORDER BY r.rolname, d.datname;

SELECT pid,
       now() - query_start AS running_for,
       state,
       wait_event_type,
       wait_event,
       left(query, 80) AS query
FROM pg_stat_activity
WHERE state = 'active'
  AND pid <> pg_backend_pid()
ORDER BY running_for DESC;

EXPLAIN
SELECT customer_id, sum(amount)
FROM orders
WHERE created_at >= now() - interval '30 days'
GROUP BY customer_id;

How to fix it

Each fix is labelled with what it changes. Try read-only checks and the least invasive fix first, and test changes outside production.

CREATE INDEX CONCURRENTLY ix_orders_created_at ON orders (created_at);

BEGIN;
SET LOCAL statement_timeout = '10min';
SELECT customer_id, sum(amount) FROM orders GROUP BY customer_id;
COMMIT;

ALTER ROLE app_web SET statement_timeout = '15s';
ALTER ROLE app_reporting SET statement_timeout = '5min';

UPDATE orders
SET amount = round(amount, 2)
WHERE id IN (
    SELECT id FROM orders
    WHERE amount <> round(amount, 2)
    ORDER BY id
    LIMIT 10000
);

Examples

A statement that runs longer than statement_timeout

The documentation describes statement_timeout (Client Connection Defaults) but does not print the message, so the text is quoted from the PostgreSQL 18.6 source code. This example needs a running PostgreSQL server (statement_timeout does not fire in PGlite, where pg_sleep runs to completion whatever the timeout), so it was not reproduced here.

SET statement_timeout = '2s';
SELECT pg_sleep(5);

ERROR:  canceling statement due to statement timeout

Cancelling a query from another session

Session 1 receives the error; in session 2 pg_cancel_backend returns true. The documentation describes pg_cancel_backend (Server Signaling Functions) but does not print the message, so the text is quoted from the PostgreSQL 18.6 source code; the pid is illustrative. This example needs a running PostgreSQL server (two concurrent sessions), which PGlite does not provide, so it was not reproduced here.

-- Session 1 (pid 12345)
SELECT pg_sleep(600);

-- Session 2
SELECT pg_cancel_backend(12345);

ERROR:  canceling statement due to user request

How to prevent it

Set statement_timeout deliberately per role or per application connection rather than server-wide, choose values that match each workload, and use SET LOCAL for the few jobs that need more. Monitor slow queries (for example with pg_stat_statements) so a query that is creeping towards the limit is tuned before it starts failing.

Treat 57014 in the application as "the work was not done": the statement (and an open transaction) was rolled back. Retry only if the operation is idempotent and the cause was temporary, such as a lock wait; retrying a query that is simply too slow just repeats the timeout.

Common questions

Learn more on CodeWithSQL

• SQL performance tuning guide
• How SQL indexes improve performance

Official documentation

• Client connection defaults (statement_timeout, lock_timeout)
• Server signaling functions (pg_cancel_backend)
• libpq: canceling queries in progress
• The cumulative statistics system (pg_stat_activity)

Last technically reviewed 24 October 2026; examples and diagnostics run on PostgreSQL 18.6 documentation; SQL-level parts in PGlite 0.5.11. SQL-level examples were run in PGlite (PostgreSQL compiled to WebAssembly); examples that need a running server are shown as documented in the PostgreSQL documentation.