57014
Read PG 18 manual ↗query_canceled
- SQLSTATE
- 57014
- Condition name
- query_canceled
- Class
- Operator Intervention
- Source macro
- ERRCODE_QUERY_CANCELED
- Evidence
- Observed at runtime in the source evidence
English SQLSTATE atlas: authored explanations and source/runtime evidence are separate from the manual definitions. View source ↗
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.
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.txtsrc.postgres.18.6—postgres.cdoc.config.18— Statement behavior and statement_timeout- Runtime:
57014-registry-final-20260909on latest and pg10; structured observations are in the public evidence JSON
Source evidence
Evidence belongs to the frozen source and runtime versions listed here. It is not a runtime verification of the selected manual version.
57014 is the query_canceled condition in Class 57 operator_intervention.
Method: Read the Class 57 section and 57014 row in the frozen errcodes.txt snapshot.
Limits: The directory condition covers several cancellation sources.
The statement-timeout interrupt path reports ERRCODE_QUERY_CANCELED with canceling statement due to statement timeout.
Method: Read the ProcessInterrupts timeout branch and the official statement_timeout behavior documentation.
Limits: User cancel, lock timeout, recovery conflict, and administrative cancel paths can use the same SQLSTATE with different messages or effects.
A 100 ms statement_timeout canceled pg_sleep(1) with SQLSTATE 57014 and left the autocommit connection IDLE; SELECT 1 then returned 1 on both targets.
Method: Set statement_timeout, execute the long sleep, capture diagnostics and status, and assert the follow-up query and final status.
Limits: The run covers statement timeout on an autocommit connection and does not establish transaction effects for canceled writes or explicit transactions.
case-manifest.57014 snippet-registry.57014.final runtime.57014-registry-final-20260909.latest runtime.57014-registry-final-20260909.pg10
The locked catalogue records 57014 in every listed formal snapshot from 9.0.23 through 18.6 and in 19beta3; pre-9.0 history is not scanned.
Method: Read the manifest snapshots and definition references for the code.
Limits: The first scanned release is a lower bound, not an asserted introduction version.
- src/backend/utils/errcodes.txt · REL_18_6 · lines 432-438
724edf9bde9d356724ad384a2e196edc3c9f80f7 - src/backend/tcop/postgres.c · REL_18_6 · lines 3441-3446
724edf9bde9d356724ad384a2e196edc3c9f80f7 - doc/src/sgml/config.sgml · PG18-docs · statement_timeout configuration
724edf9bde9d356724ad384a2e196edc3c9f80f7 - doc/src/sgml/protocol.sgml · PG18-docs · ErrorResponse fields
724edf9bde9d356724ad384a2e196edc3c9f80f7 - sources/manifest.lock.json · · snapshots and definition_blobs entries for the 57014 definition
- verify/cases/57014/cases.json · · statement_timeout_cancel
- verify/cases/57014/snippets.json · · statement_timeout_cancel ordered SQL
Message templates
explicit ERROR · message.statement-timeout
Primary
canceling statement due to statement timeout
This template identifies the statement_timeout path; other query-canceled paths have their own messages.
Reproduction & repair cases
statement_timeout_cancel · PG 10, 18
Preconditions
- A dedicated connection
- statement_timeout set to 100 ms
Trigger: Run pg_sleep(1) and let the server cancel the statement at the configured timeout.
Expected assertions
- SQLSTATE is 57014
- The message identifies statement timeout
- The autocommit connection is usable for a subsequent query
Repair: Classify timeout by operation and budget; tune the timeout or query, and do not treat cancellation as proof that all server work has stopped without checking the operation.
Cleanup: Drop the case schema with an owner connection.
Recorded runtime evidence
18.6 (Homebrew) · passed
Run: 57014-registry-final-20260909
{
"followup": 1,
"statuses": {
"after_cancel": "IDLE",
"after_followup": "IDLE"
},
"diagnostic": {
"severity": "ERROR",
"sqlstate": "57014",
"source_file": "postgres.c",
"source_line": "3446",
"message_primary": "canceling statement due to statement timeout",
"source_function": "ProcessInterrupts"
}
}10.21 (Debian 10.21-1.pgdg90+1) · passed
Run: 57014-registry-final-20260909
{
"followup": 1,
"statuses": {
"after_cancel": "IDLE",
"after_followup": "IDLE"
},
"diagnostic": {
"severity": "ERROR",
"sqlstate": "57014",
"source_file": "postgres.c",
"source_line": "3018",
"message_primary": "canceling statement due to statement timeout",
"source_function": "ProcessInterrupts"
}
}Definition snapshot: english-manuals:f892e336620c94aacdb5113a32f… · English manual source