PostgreSQL Error 57014: Query Canceled

PostgreSQL SQLSTATE 57014 is query_canceled. It means the server canceled the current statement, but the code alone does not identify what requested the cancellation. The message may say canceling statement due to statement timeout or canceling statement due to user request. PostgreSQL lists 57014 in its error-code appendix.

Check the effective timeout in the same session

Run these in the connection that produced the error:

SHOW statement_timeout;
SHOW lock_timeout;

statement_timeout cancels a statement that runs longer than its configured limit. A value of 0 disables this server-side timeout for the current session. lock_timeout applies only while waiting to acquire a lock; PostgreSQL reports a lock timeout as SQLSTATE 55P03 (lock_not_available), not 57014. See PostgreSQL Error 55P03 troubleshooting, PostgreSQL’s client connection defaults, and error-code appendix.

To see the active value and where it came from, query pg_settings:

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

The effective setting can come from a server default, database or role setting, connection startup option, or a SET command in the session. Check the application and connection-pool configuration as well as server configuration; a reused session can keep settings applied by earlier commands.

If the statement timeout is too short

Do not disable the timeout globally just to make one query succeed. First identify the statement and why it runs longer than expected. A temporary session-level adjustment is:

SET statement_timeout = '30s';

Inside an explicit transaction, use SET LOCAL to limit the change to that transaction:

BEGIN;
SET LOCAL statement_timeout = '30s';
-- Run the statement that needs the longer limit.
COMMIT;

Use a limit appropriate for the application and reset session-level settings before returning pooled connections. PostgreSQL documentation says setting statement_timeout in postgresql.conf is not recommended because it affects all sessions. For a slow query, inspect its plan with EXPLAIN; EXPLAIN ANALYZE executes the statement, so use it only when running the query is safe.

If a client or administrator canceled the query

If the message says due to user request, check whether the application, SQL client, job scheduler, request deadline, or an administrator sent a cancel request. A server-side cancel can also be sent with pg_cancel_backend:

SELECT pid, usename, application_name, state, query_start, wait_event_type, wait_event, query
FROM pg_stat_activity
WHERE state = 'active'
  AND pid <> pg_backend_pid()
ORDER BY query_start;

An authorized administrator can cancel a selected backend’s current statement:

SELECT pg_cancel_backend(12345);

Replace 12345 with the intended backend PID. This cancels its current query, not the whole session. PostgreSQL restricts which sessions a role can cancel; see the pg_cancel_backend documentation and query-cancellation protocol.

If the error occurs inside an explicit transaction, roll back the failed transaction (or to a savepoint) before issuing more statements. Otherwise PostgreSQL will report Error 25P02: current transaction is aborted.

Distinguish a server cancellation from a client timeout

If the application reports a timeout but provides no PostgreSQL SQLSTATE, the client or driver may have stopped waiting before the server returned an error. Compare application logs, client-side query deadlines, and server logs. PostgreSQL can log the statement that exceeded the timeout when log_min_error_statement is configured to include ERROR; see error reporting and logging.

For other SQLSTATE guides, browse PostgreSQL Error Troubleshooting.