# 0B000 — invalid_transaction_initiation

> Source-bounded reference for PostgreSQL SQLSTATE 0B000.
---

# 0B000

## At a glance {#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.

<!-- BEGIN SQLSTATE FACTS: generated by scripts/generate.py; do not edit -->

| 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 | `—` |

<!-- source facts: data/errcodes/0B000.json -->
<!-- END SQLSTATE FACTS -->

## Meaning {#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 {#messages}

No fixed PostgreSQL message variant was adopted for this condition because the bounded scan did not resolve a native emitting call.

## Diagnosis {#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 {#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 {#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 {#related}

[`25001`](../25001/), [`25P02`](../25p02/)

## Sources {#sources}

The fixed [errcodes definition](https://github.com/postgres/postgres/blob/724edf9bde9d356724ad384a2e196edc3c9f80f7/src/backend/utils/errcodes.txt#L123) establishes the catalogue row; the [transaction-management documentation](https://www.postgresql.org/docs/18/tutorial-transactions.html) explains PostgreSQL transaction boundaries. The locked core/contrib call scan found no resolved 0B000 report group. See the structured [evidence record](../data/evidence/0b000.json) for fixed source paths, scan scope, and unresolved runtime boundaries.