40001 serialization_failure

速览

40001 是 PostgreSQL 类别 40 transaction_rollback 中的 serialization_failure 条件。它告诉客户端，事务观察到的顺序无法与并发事务组成可串行化顺序，因此 PostgreSQL 中止冲突事务，让客户端重新执行。

代表性案例启动两个 SERIALIZABLE 事务，让它们读取同一值。第一个事务更新并提交；旧快照事务随后收到 could not serialize access due to concurrent update，进入 INERROR，只有 ROLLBACK 后才回到 IDLE。新的可串行化事务读取已提交值，执行 registry 中固定的 SET value = 2 操作并提交最终结果；这证明的是事务边界，不是业务计算逻辑。

运行 40001-manual-boundary-final-20260909 在 PostgreSQL 18.6 和隔离的 PostgreSQL 10.21 上均通过。逐目标断言和结构化观察见公开证据 JSON。

含义与触发路径

在 SERIALIZABLE 隔离级别下，PostgreSQL 跟踪谓词和元组冲突；如果事务结果依赖一个无法串行化的顺序，就会拒绝该事务。旧事务更新之前已读取、后来被并发事务更新的行，是其中一个具体路径。SQLSTATE 说明事务结果，不说明业务操作是否应该重试。

执行器的更新路径使用 ERRCODE_T_R_SERIALIZATION_FAILURE 和 could not serialize access due to concurrent update 源码报文。其他序列化冲突可能使用不同报文，恢复冲突也可能附带 detail，但仍表达事务回滚语义。应用日志应保存完整诊断以及事务的读写集合。

40001 与 23505 不同：用户主动请求的重复值不自动成为序列化失败，即使某些并发生成键的设计会产生应用认为可重试的唯一冲突。应根据操作语义和完整事务历史决定重试策略。

报文与诊断

下面的调度需要两个会话分别建立最初的快照。最后一段使用新的连接和新的可串行化快照，这是完整重试的必要部分。

CREATE TABLE serial_rows(id integer PRIMARY KEY, value integer NOT NULL);
INSERT INTO serial_rows VALUES (1, 0);

-- 在第一次提交前打开两个 SERIALIZABLE 快照。
BEGIN ISOLATION LEVEL SERIALIZABLE;
BEGIN ISOLATION LEVEL SERIALIZABLE;

-- first 会话读到 0；stale 会话也读到同一个 0。
SELECT value FROM serial_rows WHERE id = 1;
SELECT value FROM serial_rows WHERE id = 1;

-- first 会话写入 1 并提交；随后 stale 会话用旧快照写入。
UPDATE serial_rows SET value = 1 WHERE id = 1;
COMMIT;
UPDATE serial_rows SET value = 2 WHERE id = 1;
-- UPDATE 报告 40001，事务变为 INERROR。
ROLLBACK;

-- 新的重试事务：读取新值，重新执行操作并提交。
BEGIN ISOLATION LEVEL SERIALIZABLE;
SELECT value FROM serial_rows WHERE id = 1;
UPDATE serial_rows SET value = 2 WHERE id = 1;
COMMIT;
SELECT value FROM serial_rows WHERE id = 1;

PostgreSQL 18.6 返回：

SQLSTATE: 40001
severity: ERROR
message_primary: could not serialize access due to concurrent update
message_detail: <none>
source: nodeModifyTable.c / ExecUpdate / line 2604

PostgreSQL 10.21 的主报文相同，nodeModifyTable.c 行号随版本变化。本路径没有 message_detail；其他冲突来源可能附带更多字段。SQLSTATE 和事务已经中止的状态是稳定的重试信号。

诊断

记录 SQLSTATE、严重级别、主报文、detail、hint、上下文、隔离级别、建立快照的语句以及事务状态。确认哪个事务先提交，以及哪些读取已过期。runner 断言两个初始读取都是 0，first 提交后为 IDLE，stale 事务在回滚前为 INERROR。

不要在失败事务上继续查询。先回滚，再以新的事务开始，并重复完整的读取、决策和写入。只重放最后一条 UPDATE 可能基于已经失效的快照作出决定。

处理与修复

当操作为此设计时，应把 40001 当作事务重试信号：

• 回滚整个失败事务并释放锁。
• 按要求的隔离级别启动新事务，重新读取业务决策依赖的所有值。
• 使用有限退避和最大重试次数重新执行操作。
• 让操作具备幂等性，并在提交后验证最终业务结果。

代表性重试读取 1、写入 2、以 IDLE 状态提交，独立读取观察到最终值 2。这个隔离案例中的固定赋值不能证明生产环境任意计算都可重放；应用必须从新快照重新计算。

版本与边界

目录在 PostgreSQL 7.4 的锁定定义中已观察到 40001，并持续到 8.4.22 的 pre-9.0 定义；随后在列出的所有正式快照直到 PostgreSQL 18.6 以及 PostgreSQL 19 Beta 3 预览中存在。这是 definition_only 的存在边界，不是确切实现引入版本或运行时使用断言。9.0 到 9.1 之间记录了类别标题变化；目录保留该变化，扫描范围内条件没有其他定义变化。

旧快照更新案例在 PostgreSQL 18.6 和 10.21 上均通过。源码行号和冲突 detail 会因版本和冲突类型变化。本证据只覆盖旧快照更新及其新的完整重试，不声称所有 40001 路径使用相同报文，也不声称所有事务都能安全重试。

相关

40P01 — deadlock_detected 同样会中止事务并可能要求完整重试，但触发原因是锁环。23505 — unique_violation 是不同的完整性条件，不能自动重试。23503 — foreign_key_violation 可能是持久的数据关系错误。25P02 — in_failed_sql_transaction 是失败事务回滚前的后续状态。

来源

• 核验材料 verify/cases/40001/cases.json f763521e
• 核验材料 doc/src/sgml/mvcc.sgml PG18-docs 724edf9bd 4b7bf77e
• 核验材料 doc/src/sgml/protocol.sgml PG18-docs 724edf9bd 745339e0
• 核验材料 sources/manifest.lock.json 1727a275
• 核验材料 verify/cases/40001/snippets.json 7ed0b0bf
• 核验材料 src/backend/utils/errcodes.txt REL_18_6 724edf9bd 6e8de346
• 核验材料 src/backend/executor/nodeModifyTable.c 第 2595–2605 行 REL_18_6 724edf9bd 0fc3cb18