# 01000 — warning

> PostgreSQL uses SQLSTATE 01000 for the generic warning condition. Separate directory classification from the actual WARNING or NOTICE severity, then diagnose the emitting subsystem.
---

## At a glance {#at-a-glance}

`01000` is the generic `warning` condition in Class 01, `Warning`. It is a directory classification, not a description of one particular subsystem or message. PostgreSQL's source directory explicitly says not to use this class for failure conditions.

The five-character code must be read together with the protocol severity and the complete diagnostic. In an `ErrorResponse` or `NoticeResponse`, `S` is the possibly localized severity and `V` is the nonlocalized severity. A message can therefore arrive as `WARNING`, `NOTICE`, `INFO`, or another notice level while its SQLSTATE is still `01000` when the emitting code supplied that code explicitly.

For the common default path, PostgreSQL maps `ereport(WARNING, ...)` to `01000`, levels at or above `ERROR` to `XX000`, and lower levels to `00000`. An explicit `errcode()` can override that default. This is why the directory's `W` marker is useful, but it does not by itself prove that the wire message was an actual `WARNING`.

The representative `generic_warning_boundary` probe passed on PostgreSQL 18.6 and 10.21. It uses PL/pgSQL `RAISE WARNING` to verify the default `01000` dispatch, receives an actual `WARNING` notice, and keeps the autocommit connection usable. It does not exercise the asynchronous `NOTIFY`, hstore, XID, or MultiXact warning paths.

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

| Field | Value |
| --- | --- |
| SQLSTATE | `01000` |
| Condition | `warning` |
| 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_WARNING` |
| Aliases | `—` |

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

The locked catalogue has a pre-9.0 presence observation at PostgreSQL 7.4 and records `01000` in every listed formal snapshot from 9.0.23 through 18.6 plus the 19 Beta 3 preview. The pre-9.0 source scan covers 7.4 through 8.4.22; candidate source gaps remain for 7.0 through 7.3. This is a known presence boundary, not an exact introduction version.

## Meaning and trigger paths {#meaning}

The locked 18.6 definition is `01000 W ERRCODE_WARNING warning` under Class 01. The default severity mapping is in `elog.c`: an `ERROR` or higher level starts with `ERRCODE_INTERNAL_ERROR`, a `WARNING` level starts with `ERRCODE_WARNING`, and lower levels start with `ERRCODE_SUCCESSFUL_COMPLETION`. The later error construction can replace that initial code.

Several real paths use the generic warning code:

- The asynchronous notification queue reports `NOTIFY queue is %.0f%% full`. When an old listener transaction is identified, it adds a detail naming the PID and a hint to end that transaction. This is a queue pressure warning, not an array, privilege, or constraint failure.
- Transaction ID and MultiXact wraparound protection reports that a database must be vacuumed within a remaining number of transactions or MultiXact IDs. Its hints point to a database-wide `VACUUM` and to old prepared transactions or stale replication slots.
- The SPI cleanup path explicitly supplies `ERRCODE_WARNING` for a non-empty SPI stack and points to missing `SPI_finish` calls. Here the code is explicit even though the severity is also `WARNING`.

These source-confirmed examples show why the message, detail, hint, source context, and operation are more actionable than `01000` alone. Other Class 01 conditions, such as `01003` or `0100C`, have their own SQLSTATEs and should not be collapsed into this generic code.

## Messages and diagnostics {#messages}

The executable representative is the registry entry `generic_warning_boundary`:

<!-- BEGIN SQLSTATE SNIPPET: generic_warning_boundary -->
```sql
DO $$ BEGIN RAISE WARNING 'calibration warning'; END $$;
SELECT 1;
```
<!-- END SQLSTATE SNIPPET -->

Both PostgreSQL 18.6 and 10.21 delivered the warning through the notice channel with `SQLSTATE 01000`, severity `WARNING`, and primary message `calibration warning`. The follow-up `SELECT 1` succeeded and the connection was `IDLE`. This is a real `RAISE WARNING` dispatch check; it is not runtime evidence for the separate `NOTIFY` queue, hstore compatibility, transaction-ID, or MultiXact paths listed above.

## Diagnosis {#diagnosis}

Capture `C`/`sqlstate`, `S`, `V`, `M`, `D`, and `H` from the driver or protocol, together with the statement, database, backend PID, and timestamp. In a client library with a notice handler, record notices as well as exceptions: a warning-level `NoticeResponse` can be delivered without raising a statement exception. Keep the original localized message and the nonlocalized severity when available.

Check `SHOW client_min_messages` and `SHOW log_min_messages` when a message is missing from the client or server log. Those settings control delivery and logging thresholds; they do not change the underlying cause. For a repeated warning, search logs by SQLSTATE and the stable message template, then inspect the named subsystem:

- `NOTIFY queue ... full` calls for long-lived listener transactions and the PID in `DETAIL`.
- XID or MultiXact vacuum warnings call for transaction age, prepared transactions, and replication slots before wraparound protection becomes an actual failure.
- A non-empty SPI stack points toward extension or server-side SPI lifecycle handling.

Do not infer a transaction abort, a broken connection, or data corruption from `01000` alone. The representative warning left its session usable, but a later statement may fail for an independent reason, and a function or client operation may impose its own control flow.

## Response {#response}

Treat the message's subsystem and hint as the repair target. End or repair the transaction that is holding a notification queue or old transaction horizon; perform the indicated database-wide maintenance after checking replication slots and prepared transactions; or fix the extension's SPI ownership. Preserve the original diagnostic while investigating.

An actual `WARNING` or lower-level notice does not by itself put an explicit transaction into the aborted state, and it normally leaves the connection able to continue. Verify the next command and transaction status instead of assuming either outcome from the code. If a subsequent `ERROR` occurs, handle that error's SQLSTATE and recover with `ROLLBACK` or a suitable savepoint according to that error's contract.

Raising `client_min_messages` or `log_min_messages` can reduce noise, but it does not repair the queue, transaction horizon, or SPI lifecycle. Use suppression only after the underlying signal has been understood.

## Versions {#versions}

The catalogue records `01000` in the locked 7.4–8.4.22 pre-9.0 formal sources and in all formal catalogue snapshots from 9.0.23 through 18.6, plus 19 Beta 3. The same-tag `REL8_1_4` `errcodes.sgml` table already lists the older `1000` spelling with condition name `warning`, so this condition-name observation is confirmed by 8.1.4. Candidate source gaps remain for 7.0–7.3, so the 7.4 observation is a presence boundary rather than an exact introduction version. The 18.6 source snapshot is fixed at commit `724edf9bde9d356724ad384a2e196edc3c9f80f7`.

The protocol severity fields and the `client_min_messages`/`log_min_messages` controls are documented for PostgreSQL 18. The representative source paths above are 18.6 observations; their presence does not claim that every message template is unchanged in every older release.

## Related {#related}

[`00000` — `successful_completion`](../00000/) is the default low-level completion code. [`01003` — `null_value_eliminated_in_set_function`](../01003/) and [`0100C` — `dynamic_result_sets_returned`](../0100c/) are more specific Class 01 conditions. [`XX000` — `internal_error`](../xx000/) is the default code for an `ERROR` without an explicit code; it is not interchangeable with a warning. [`25P02` — `in_failed_sql_transaction`](../25p02/) describes a later command rejected because an earlier error aborted the transaction, not a consequence that should be assigned to every `01000` message.

## Sources {#sources}

The structured evidence for this page is recorded in the [public evidence JSON](../data/evidence/01000.json). The source and documentation records use fixed PostgreSQL commit `724edf9bde9d356724ad384a2e196edc3c9f80f7`; runtime records retain the exact snippet registry and run IDs for the passed probe.

- `src.errcodes.18.6` — [`errcodes.txt`](https://github.com/postgres/postgres/blob/724edf9bde9d356724ad384a2e196edc3c9f80f7/src/backend/utils/errcodes.txt#L81-L84)
- `src.elog.18.6` — [`elog.c`](https://github.com/postgres/postgres/blob/724edf9bde9d356724ad384a2e196edc3c9f80f7/src/backend/utils/error/elog.c#L442-L454)
- `src.async.18.6` — [`async.c`](https://github.com/postgres/postgres/blob/724edf9bde9d356724ad384a2e196edc3c9f80f7/src/backend/commands/async.c#L1518-L1559)
- `src.varsup.18.6` and `src.multixact.18.6` — transaction horizon warning paths
- `src.spi.18.6` — explicit warning code in the SPI cleanup path
- `doc.protocol.18` and `doc.logging.18` — [Error and Notice Message Fields](https://www.postgresql.org/docs/18/protocol-error-fields.html) and [When to Log](https://www.postgresql.org/docs/18/runtime-config-logging.html)