↑↓ 选择 ↵ 打开 ⌫ 改范围 完整检索页

pgsql.cc 提供对 postgresql.org 官网内容的中文翻译，由 Pigsty 团队维护。

文档 / SQL 状态码 / Class 01 警告

01000 warning

警告

WARNING 已实测 参考 实测通过

类别
Class 01 警告
严重等级
WARNING
条件名
warning
宏名称
ERRCODE_WARNING
启用版本
7.4
状态
活跃

版本覆盖

  1. 18
  2. 17
  3. 16
  4. 15
  5. 14
  1. 13
  2. 12
  3. 11
  4. 10
  1. 19 beta
  2. 20 dev

速览

01000 是类别 01 Warning 中的通用警告（warning）条件。它只是目录分类，不对应某一个固定子系统或固定报文。PostgreSQL 源码目录明确说明，不应把这个类别用于失败条件。

这个五字符代码必须和协议严重级别及完整诊断一起读取。在 ErrorResponse 或 NoticeResponse 中，S 是可能经过本地化的严重级别，V 是未本地化的严重级别。因此，当产生消息的代码显式提供了该代码时，SQLSTATE 仍可以是 01000，而消息严重级别可能是 WARNING、NOTICE、INFO 或其他提示级别。

在常见的默认路径中，PostgreSQL 将 ereport(WARNING, ...) 映射为 01000，将不低于 ERROR 的级别映射为 XX000，将更低的级别映射为 00000。显式的 errcode() 可以覆盖这个默认值。因此，目录中的 W 标记有参考价值，但单凭它不能证明线上协议消息一定是实际的 WARNING。

代表性案例 generic_warning_boundary 在 PostgreSQL 18.6 和 10.21 上均通过。它用 PL/pgSQL RAISE WARNING 核验默认的 01000 分发，实际收到 WARNING 提示，并保持自动提交连接可继续使用。它没有实测异步 NOTIFY、hstore、XID 或 MultiXact 警告路径。

锁定目录在 PostgreSQL 7.4 的 pre-9.0 正式源码中已经观察到该代码，并确认它存在于 9.0.23 至 18.6 的每个正式快照及 19 Beta 3 预览快照。pre-9.0 源码扫描覆盖 7.4 至 8.4.22；7.0 至 7.3 仍有候选源码缺口。因此，7.4 是已知存在边界，不是精确引入版本。

含义与触发路径

锁定的 18.6 定义是在类别 01 下的 01000 W ERRCODE_WARNING warning。默认严重级别映射位于 elog.c：ERROR 或更高级别从 ERRCODE_INTERNAL_ERROR 开始，WARNING 级别从 ERRCODE_WARNING 开始，更低级别从 ERRCODE_SUCCESSFUL_COMPLETION 开始。随后构造错误消息时还可以替换这个初始代码。

若干真实路径会使用通用警告（warning）代码：

  • 异步通知队列会报告 NOTIFY queue is %.0f%% full。如果找到最老的监听事务，还会附带指出 PID 的详细信息，并提示结束该事务。这是队列压力警告，不是数组、权限或约束失败。
  • 事务 ID 和 MultiXact 回卷保护会报告某个数据库必须在剩余多少事务或 MultiXact ID 用完前执行 VACUUM。提示会指向全库 VACUUM，以及旧预备事务或陈旧复制槽。
  • SPI 清理路径会显式提供 ERRCODE_WARNING，报告非空 SPI 栈，并提示检查遗漏的 SPI_finish。这里的代码是显式指定的，即使严重级别同样是 WARNING。

这些源码确认的例子说明，报文、详细信息、提示、源码上下文和操作比单独的 01000 更有行动价值。其他类别 01 条件（如 01003 或 0100C）拥有自己的 SQLSTATE，不应全部折叠成这个通用代码。

报文与诊断

可执行的代表性案例是注册表中的 generic_warning_boundary：

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

PostgreSQL 18.6 和 10.21 都通过提示通道送出这条警告，得到 SQLSTATE 01000、严重级别 WARNING 和主报文 calibration warning。后续的 SELECT 1 成功，连接状态为 IDLE。这是实际的 RAISE WARNING 分发核验，不是上面分别列出的 NOTIFY 队列、hstore 兼容、事务 ID 或 MultiXact 路径的运行时证据。

报文模板

源码里的格式串，不是某一次运行的输出。%s 之类是占位符，实际报文会填入对象名与取值。适用范围一栏是核验时留下的原始英文记录，未经翻译。

主消息 NOTIFY queue is %.0f%% full
DETAIL The server process with PID %d is among those with the oldest transactions.
HINT The NOTIFY queue cannot be emptied until that process ends its current transaction.

来源：src/backend/commands/async.c（lines 1518-1559） @ REL_18_6

适用范围：DETAIL and HINT are conditional on finding an oldest listener process.

主消息 database "%s" must be vacuumed within %u transactions
HINT To avoid transaction ID assignment failures, execute a database-wide VACUUM in that database. You might also need to commit or roll back old prepared transactions, or drop stale replication slots.

来源：src/backend/access/transam/varsup.c（lines 168-179） @ REL_18_6

适用范围：The remaining count and optional follow-up text are calculated from live transaction state.

主消息 · singular database "%s" must be vacuumed before %u more MultiXactId is used
主消息 · plural database "%s" must be vacuumed before %u more MultiXactIds are used
HINT Execute a database-wide VACUUM in that database. You might also need to commit or roll back old prepared transactions.

来源：src/backend/access/transam/multixact.c（lines 1287-1300） @ REL_18_6

适用范围：The singular/plural selection and remaining count depend on live MultiXact state.

主消息 transaction left non-empty SPI stack
HINT Check for missing "SPI_finish" calls.

来源：src/backend/executor/spi.c（lines 467-472） @ REL_18_6

适用范围：This template belongs to SPI cleanup and does not describe every 01000 path.

主消息 calibration warning

适用范围：This message is supplied by the representative probe and is not a built-in template for the NOTIFY, hstore, XID, or MultiXact paths.

诊断

从驱动或协议中记录 C/sqlstate、S、V、M、D、H，并同时记录语句、数据库、后端 PID 和时间戳。带有提示处理器的客户端还应记录提示，而不只是异常：WARNING 级别的 NoticeResponse 可以在不抛出语句异常的情况下送达。若有 V，请保留本地化严重级别与未本地化值。

当客户端或服务器日志中看不到消息时，检查 SHOW client_min_messages 和 SHOW log_min_messages。这些设置控制送达与记录阈值，不会改变根因。对于重复出现的警告（warning），使用 SQLSTATE 和稳定的报文模板搜索日志，再检查对应子系统：

  • NOTIFY queue ... full 应检查长期存活的监听事务及 DETAIL 中的 PID。
  • XID 或 MultiXact 回收警告应在回卷保护变成真实失败之前检查事务年龄、预备事务和复制槽。
  • 非空 SPI 栈应指向扩展或服务器端 SPI 生命周期管理。

不能仅凭 01000 推断事务已经中止、连接已经损坏或数据已经损坏。代表性警告让会话保持可用，但后续语句可能因独立原因失败，函数或客户端操作也可能施加自己的控制流。

处理

以报文中的子系统和提示作为修复目标。结束或修复占住通知队列或旧事务回收边界的事务；检查复制槽和预备事务后执行提示的全库维护；或者修复扩展的 SPI 所有权。调查时保留原始诊断。

实际的 WARNING 或更低级别提示本身不会把显式事务置为中止，通常也会让连接保持可继续使用。应验证下一条命令及事务状态，不要从代码本身猜测结果。如果随后出现 ERROR，请按照那个错误的 SQLSTATE 处理，并根据其事务契约使用 ROLLBACK 或合适的保存点恢复。

提高 client_min_messages 或 log_min_messages 可以减少噪声，但不会修复队列、事务回收边界或 SPI 生命周期。只有理解了底层信号后才应考虑抑制它。

可复现案例

在一次性实例上执行过的场景。其中 1 个附有可执行 SQL，正文相应小节里给出。

generic_warning_boundary PG 10 / 18 有 SQL

前置条件

  • A disposable session with a notice handler

触发

Execute a PL/pgSQL RAISE WARNING dispatch probe.

断言

  • The notice handler receives SQLSTATE 01000 and WARNING severity
  • The warning message is preserved
  • The session remains IDLE and a follow-up query succeeds
  • The probe is not presented as the hstore_compat.c natural warning path

处置

Treat the warning's message and context as the actionable signal; identify the emitting subsystem before changing data.

清理

No persistent runtime resources are created.

版本

目录记录 01000 存在于锁定的 7.4–8.4.22 pre-9.0 正式源码，以及 9.0.23 至 18.6 的所有正式目录快照和 19 Beta 3 预览快照。同 tag 的 REL8_1_4 errcodes.sgml 表已经用较早的 1000 写法列出条件名 warning，因此至少可以确认 8.1.4 已有该条件名。7.0–7.3 仍有候选源码缺口，因此 7.4 观察结果只是存在边界，不是精确引入版本。18.6 源码快照固定在 commit 724edf9bde9d356724ad384a2e196edc3c9f80f7。

协议严重级别字段以及 client_min_messages/log_min_messages 控制项以 PostgreSQL 18 文档为依据。上面的代表性源码路径是 18.6 观察结果，不表示每个旧版本中的所有报文模板都完全不变。

来源

证据

断言

每条断言都写明了是怎么核实的，以及它不覆盖什么。这一层是核验时留下的原始英文记录，照原样呈现，未经翻译。

  • 01000 is the generic warning condition in Class 01, and the directory comment says not to use Class 01 for failure conditions.

    核实方式Read the Class 01 section and the 01000 row in the frozen errcodes.txt snapshot.

    不覆盖Directory identity does not identify the emitting subsystem or prove a runtime occurrence.

    来源src/backend/utils/errcodes.txt（lines 81-84）

  • Without a later explicit errcode, PostgreSQL initializes ERROR and higher levels as XX000, WARNING as 01000, and lower levels as 00000.

    核实方式Read the default sqlerrcode selection in errstart() in the fixed 18.6 source.

    不覆盖An explicit errcode in the ereport construction can replace this initial value; the mapping does not classify every notice by message text.

    来源src/backend/utils/error/elog.c（lines 442-454）

  • The asynchronous notification queue emits a WARNING with SQLSTATE 01000 by default when its usage reaches the warning path, with conditional PID detail and a hint to end the oldest transaction.

    核实方式Read asyncQueueFillWarning() and its ereport(WARNING) construction.

    不覆盖The warning is rate-limited and conditional on queue usage and an identifiable old listener; the source path is not a promise that every installation will observe it.

    来源src/backend/commands/async.c（lines 1518-1559）

  • Transaction ID and MultiXact horizon checks emit warning messages and maintenance hints for a database approaching its configured horizon.

    核实方式Read the ereport(WARNING) branches and their VACUUM, prepared-transaction, and replication-slot hints.

    不覆盖These are source-confirmed paths; their conditions and remaining-count values depend on live transaction state.

    来源src/backend/access/transam/varsup.c（lines 168-179） · src/backend/access/transam/multixact.c（lines 1287-1300）

  • The SPI cleanup path explicitly supplies ERRCODE_WARNING for a non-empty SPI stack and reports a missing SPI_finish hint.

    核实方式Read the commit cleanup branch at lines 467-472 in the fixed source.

    不覆盖This warning requires an SPI lifecycle defect; it is not a generic SQL warning trigger.

    来源src/backend/executor/spi.c（lines 467-472）

  • The protocol carries localized S and nonlocalized V severity fields; error messages use ERROR/FATAL/PANIC while notice messages can use WARNING, NOTICE, DEBUG, INFO, or LOG.

    核实方式Read the official Error and Notice Message Fields table in the PostgreSQL 18 documentation.

    不覆盖The fields describe the wire message; they do not change the SQLSTATE directory row.

    来源doc/src/sgml/protocol.sgml（lines 6254-6290, ErrorResponse/NoticeResponse severity fields）

  • client_min_messages and log_min_messages control which messages are delivered to clients or written to the server log.

    核实方式Read the PostgreSQL 18 runtime logging configuration entries.

    不覆盖Thresholds affect visibility, not the underlying emitting condition, and configuration can differ between sessions and servers.

    来源doc/src/sgml/config.sgml（lines 7142-7190 and 9721-9760, message logging thresholds）

  • The catalogue records 01000 in the locked 7.4–8.4.22 pre-9.0 formal sources and every listed formal snapshot from 9.0.23 through 18.6 and 19beta3. The same-tag REL8_1_4 errcodes.sgml row already lists the older 1000 spelling with condition name warning, confirming that condition-name observation by 8.1.4. Candidate source gaps remain for 7.0–7.3, so 7.4 is a presence boundary rather than an exact introduction version.

    核实方式Read the manifest snapshots and the same-tag REL8_1_4 errcodes.sgml row for the 01000 definition; the per-code history file is a derived view of these locked records.

    不覆盖The pre-9.0 source set is locked through 8.4.22 but candidate source gaps remain for 7.0–7.3; observed presence is not an asserted introduction version.

    来源sources/manifest.lock.json（snapshots and definition_blobs entries for the 01000 definition） · doc/src/sgml/errcodes.sgml（REL8_1_4 table rows 93-95; the older table renders 01000 as 1000）

  • The generic_warning_boundary case delivered an observed WARNING with SQLSTATE 01000 and the calibration warning message on PostgreSQL 18.6 and 10.21; the autocommit connection remained IDLE and accepted SELECT 1.

    核实方式Read the stable case and ordered snippet registry, then compare the warning notice, SQLSTATE, severity, followup, and IDLE status in both final run summaries and raw records.

    不覆盖This runtime result covers the PL/pgSQL RAISE WARNING dispatch probe only; it is not runtime evidence for the separate NOTIFY queue, hstore, XID, or MultiXact paths.

    来源verify/cases/01000/cases.json（generic_warning_boundary） · verify/cases/01000/snippets.json（generic_warning_boundary ordered probe and followup）

运行记录

目标服务器版本结果覆盖案例
latest 18.6 (Homebrew) passed generic_warning_boundary
pg10 10.21 (Debian 10.21-1.pgdg90+1) passed generic_warning_boundary

同类 SQL 状态码

状态码 条件名 宏名称 严重等级 版本
Class 01 警告 Warning 8 个 ↗
01000 warning ERRCODE_WARNING WARNING 7.4
类别 01 的通用警告，需结合实际严重级别判断。 活跃
01003 null_value_eliminated_in_set_function ERRCODE_WARNING_NULL_VALUE_ELIMINATED_IN_SET_FUNCTION WARNING 7.4
集合函数计算时消除了 NULL 值的警告。 活跃
01004 string_data_right_truncation ERRCODE_WARNING_STRING_DATA_RIGHT_TRUNCATION WARNING 7.4
字符串数据被右截断的警告条件。 活跃
01006 privilege_not_revoked ERRCODE_WARNING_PRIVILEGE_NOT_REVOKED WARNING 8.0
REVOKE 未撤销或未完全撤销权限的警告。 活跃
01007 privilege_not_granted ERRCODE_WARNING_PRIVILEGE_NOT_GRANTED WARNING 8.0
GRANT 未授予或未完全授予权限的警告。 活跃
01008 implicit_zero_bit_padding ERRCODE_WARNING_IMPLICIT_ZERO_BIT_PADDING WARNING 7.4
位串被隐式补零填充的警告条件。 活跃
0100C dynamic_result_sets_returned ERRCODE_WARNING_DYNAMIC_RESULT_SETS_RETURNED WARNING 7.4
过程返回了动态结果集的警告条件。 活跃
01P01 deprecated_feature ERRCODE_WARNING_DEPRECATED_FEATURE WARNING 8.0
使用已弃用功能的警告，如 MD5 密码。 活跃