0B000 — invalid_transaction_initiation
0B000
At a glance
SQLSTATE 0B000 names the SQL-standard Invalid Transaction Initiation class. The locked PostgreSQL 18.6 definition contains the condition, but the resolved core/contrib call scan did not identify a PostgreSQL report group for this code. Treat the class as an identity and investigation starting point, not as proof that a particular BEGIN, savepoint, or client command emits it.
| Field | Value |
|---|---|
| SQLSTATE | 0B000 |
| Condition | invalid_transaction_initiation |
| Status | active |
| Known present by | 7.4 |
| Locked snapshots | 9.0.23, 9.1.24, 9.2.24, 9.3.25, 9.4.26, 9.5.25, 9.6.24, 10.23, 11.22, 12.22, 13.23, 14.24, 15.19, 16.15, 17.11, 18.6, 19beta3 |
| Macros | ERRCODE_INVALID_TRANSACTION_INITIATION |
| Aliases | — |
Meaning
The class concerns an invalid way to initiate or establish a transaction in an implementation that uses this SQLSTATE. It is distinct from the transaction-state code actually returned by a server. PostgreSQL’s catalogue entry alone does not establish whether a current backend path, an extension, an ECPG layer, or a driver would use 0B000 for a given command.
Messages
No fixed PostgreSQL message variant was adopted for this condition because the bounded scan did not resolve a native emitting call.
Diagnosis
Record the exact SQLSTATE, message type, severity, command phase, and client library before interpreting the name. Check whether the failure occurred during startup, an explicit transaction command, a savepoint operation, or in a wrapper that forwards a remote result. If the observed code is instead 25001 or another transaction-state code, diagnose that code and its server message; do not substitute 0B000 from the class name.
Response
Follow the actual transaction-state diagnostic: end or repair the invalid transaction command, and use a new transaction only when the server and application state require it. If a wrapper or driver owns the path, inspect its fixed implementation and the remote SQLSTATE before changing transaction handling. The bounded source result provides no basis for a generic retry or a PostgreSQL-native repair recipe for 0B000.
Versions
The locked catalogue places this condition at least by PostgreSQL 7.4. The release definitions cover the published snapshots listed in the facts block; source-path status is limited to the fixed PostgreSQL 18.6 context cited below.
Related
Sources
The fixed errcodes definition establishes the catalogue row; the transaction-management documentation explains PostgreSQL transaction boundaries. The locked core/contrib call scan found no resolved 0B000 report group. See the structured evidence record for fixed source paths, scan scope, and unresolved runtime boundaries.