57014 — query_canceled

At a glance

57014 is PostgreSQL’s query_canceled condition in Class 57, operator_intervention. It indicates that the server interrupted a statement. The same SQLSTATE covers several cancellation sources, so the primary message and server context are needed to distinguish a statement timeout, an explicit client cancel, a recovery conflict, or another administrative path.

The representative case sets statement_timeout to 100 ms and executes pg_sleep(1). PostgreSQL returns canceling statement due to statement timeout; the autocommit connection remains IDLE, and a subsequent SELECT 1 returns 1. This proves the timeout path and connection usability for this case, not that every canceled command has no side effects or the same transaction state.

Run 57014-registry-final-20260909 passed on PostgreSQL 18.6 and isolated PostgreSQL 10.21. The per-target assertions and structured observations are retained in the public evidence JSON.

Meaning and trigger paths

statement_timeout starts a timer for each statement and asks the backend to process an interrupt when the budget expires. In the fixed source path, ProcessInterrupts emits ERRCODE_QUERY_CANCELED with canceling statement due to statement timeout. A client cancel uses the same SQLSTATE with canceling statement due to user request; lock timeout and some recovery paths use their own message or detail.

Cancellation stops the current statement at an interruptible point. It is not a general assertion that all work associated with a request has ceased, that an external side effect was undone, or that a transaction is usable without rollback. The transaction boundary, statement type, and cancellation source determine what must be cleaned up.

Messages and diagnostics

The representative operation is a dedicated autocommit connection with a 100 ms timeout:

SET statement_timeout = '100ms';
SELECT pg_sleep(1);
SELECT 1;

PostgreSQL 18.6 returned:

SQLSTATE: 57014
severity: ERROR
message_primary: canceling statement due to statement timeout
source: postgres.c / ProcessInterrupts / line 3446

PG10 returned the same primary message with source line 3018. There is no universal detail template for 57014; preserve message_detail, message_hint, context, and the statement that was interrupted when present.

Diagnosis

Record SQLSTATE, severity, primary message, detail, hint, context, backend PID, statement text, timeout settings, and the source of cancellation. Distinguish statement_timeout from lock_timeout, a client cancel, an administrator request, and a standby recovery conflict. Search server logs with the SQLSTATE and backend PID when the client diagnostic is incomplete.

Check transaction status after the error. The autocommit timeout case was IDLE and accepted SELECT 1; an error inside an explicit transaction may leave it INERROR and require rollback. If the interrupted statement changed rows before an error, verify the database state rather than assuming a request-level rollback outside the current transaction.

Response and repair

Tune the operation and its budget based on the cause:

• Optimize or batch an overlong query, and set a timeout that matches the work’s service-level budget.
• Handle a client or administrative cancel as a control decision, then inspect whether the application should retry.
• Resolve lock contention separately when the message identifies lock timeout; increasing statement timeout does not repair a lock queue.
• Roll back an aborted explicit transaction before issuing unrelated commands, and verify any external work whose lifetime is not controlled by PostgreSQL.

The representative follow-up query returned 1 with the connection IDLE. That is the repair assertion for this autocommit sleep case; it is not a promise that a canceled write, cursor, or transaction can always be resumed in place.

Versions and boundaries

The catalogue has a definition-presence observation for 57014 at PostgreSQL 7.4 and through the locked 8.4.22 pre-9.0 definitions, then in every listed formal snapshot through PostgreSQL 18.6 and the PostgreSQL 19 Beta 3 preview. This is a definition-only presence boundary, not an exact implementation introduction or runtime-use claim. No condition definition change is recorded in the scanned range.

The statement-timeout case passed on PostgreSQL 18.6 and 10.21. The SQLSTATE is shared by other cancellation mechanisms whose messages and transaction effects differ, so this evidence is limited to a server-side statement timeout on an autocommit connection.

Related

40P01 — deadlock_detected is resolved by the lock manager as a cycle, not by a timeout budget. 53300 — too_many_connections is a startup capacity failure. 42P01 — undefined_table is a parse-time name error. 25P02 — in_failed_sql_transaction can follow a cancellation when the surrounding explicit transaction is aborted.

Sources

Structured evidence is recorded in the public evidence JSON. Source records are fixed to PostgreSQL commit 724edf9bde9d356724ad384a2e196edc3c9f80f7; runtime records retain both target IDs and structured observations.

• src.errcodes.18.6 — errcodes.txt
• src.postgres.18.6 — postgres.c
• doc.config.18 — Statement behavior and statement_timeout
• Runtime: 57014-registry-final-20260909 on latest and pg10; structured observations are in the public evidence JSON