01000 — warning

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.

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

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

The executable representative is the registry entry generic_warning_boundary:

DO $$ BEGIN RAISE WARNING 'calibration warning'; END $$;
SELECT 1;

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

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

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

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

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

Sources

The structured evidence for this page is recorded in the public evidence 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
• src.elog.18.6 — elog.c
• src.async.18.6 — async.c
• 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 and When to Log