PostgreSQL 的事务模型与很多数据库不同，它并不支持真正意义上的嵌套事务。当一个事务已经开启，再执行 BEGIN 或者 START TRANSACTION 时，PostgreSQL 会给出警告，并且不会开启新的事务。原因在于 PostgreSQL 的每个会话在某一时刻只能有一个活动事务，事务控制命令只作用于当前这一层。但业务上经常会遇到这样的需求：主流程中执行若干步骤，某个步骤失败后只希望回滚该步骤自身的修改，而不是整个事务。针对这类需求，PostgreSQL 提供了 SAVEPOINT 机制，可以用它模拟出类似嵌套事务的提交与回滚行为。
一、PostgreSQL 为什么不支持原生嵌套事务，保存点如何工作
要理解嵌套事务的模拟方案，先得区分“嵌套事务”和“保存点”这两个概念。嵌套事务通常指在某个事务内部还可以开启子事务，子事务可以单独提交或回滚，而父事务根据子事务结果继续执行。PostgreSQL 并没有实现这种层级化的事务结构，它提供的是 SAVEPOINT。SAVEPOINT 的本质是在事务日志中标记一个位置，之后可以通过 ROLLBACK TO SAVEPOINT 将事务状态回退到该位置，撤销从保存点建立以来所做的全部修改。这个回退是事务内部的局部回滚，不会结束整个事务。
举个最简单的例子：开始事务后插入一条员工记录，然后设置一个保存点，再更新部门表。如果更新操作不符合预期，可以回滚到保存点，这时部门表的修改被撤销，但员工记录的插入仍然保留。示例代码如下：
BEGIN; INSERT INTO employees (id, name, department_id) VALUES (1001, '王明', 3); SAVEPOINT before_dept_update; UPDATE departments SET headcount = headcount + 1 WHERE id = 3; -- 假设这里发现更新条件有误，只撤销部门表更新 ROLLBACK TO SAVEPOINT before_dept_update; COMMIT;
这段代码执行后，employees 表中会新增一条记录，而 departments 表的 headcount 不会变化。如果换成普通的事务回滚，两个修改都会丢失。从这一点看，SAVEPOINT 确实提供了局部回滚能力，足以覆盖很多模拟嵌套事务的场景。但需要注意，回滚到保存点并不会改变事务本身的状态，事务仍然处于开启状态，之后可以继续执行新语句，也可以提交或整体回滚。
与原生嵌套事务相比，SAVEPOINT 有明显的差异。以 SQL Server 为例，它允许显式开启嵌套事务，通过 COMMIT 和 ROLLBACK 控制不同层级。PostgreSQL 的保存点不能单独提交，一旦释放保存点，内部修改会合并到外层事务；一旦外层事务回滚，所有保存点中的修改也会全部消失。因此，使用 SAVEPOINT 模拟嵌套事务时，必须清楚子事务的提交并不是真正的持久化提交，只有最外层 COMMIT 成功，数据才会落盘。
二、用 PL/pgSQL 的 BEGIN EXCEPTION 块构建隐式嵌套事务
在 PostgreSQL 存储过程或函数中，PL/pgSQL 的 BEGIN 关键字有双重含义。它既可以是事务开始命令，也可以表示一个代码块的开始。当我们写 PL/pgSQL 函数时，内部的 BEGIN...END 是代码块结构，而不是开启新事务。更重要的是，如果代码块中带有 EXCEPTION 子句，PostgreSQL 会在进入该块时自动创建一个隐式保存点。当块内发生未捕获的异常时，事务会回滚到这个隐式保存点，然后进入异常处理分支，而不是让整个事务失败。
这种机制实际上就是利用保存点模拟了子事务的异常隔离。例如，我们想在一个批量处理任务中逐条处理记录，某条记录出错时记录日志并继续处理后续记录，而不是中断整个任务。可以这样写：
CREATE OR REPLACE FUNCTION process_orders()
RETURNS void
LANGUAGE plpgsql
AS $$
DECLARE
order_id INT;
BEGIN
FOR order_id IN SELECT id FROM orders WHERE status = 'pending'
LOOP
BEGIN
-- 模拟可能失败的业务处理
IF order_id % 7 = 0 THEN
RAISE EXCEPTION '订单 % 数据异常', order_id;
END IF;
UPDATE orders
SET status = 'processed'
WHERE id = order_id;
EXCEPTION
WHEN OTHERS THEN
INSERT INTO error_log (order_id, message, created_at)
VALUES (order_id, SQLERRM, now());
END;
END LOOP;
END;
$$;
在这个函数中，外层循环每处理一个 order_id 就进入一个带 EXCEPTION 的代码块。进入该块时 PostgreSQL 会生成一个隐式保存点。如果 RAISE EXCEPTION 抛出错误，事务会回滚到块开始的保存点，这样当前订单的 UPDATE 没有执行，但之前已经处理成功的订单不会受到影响。随后异常处理分支写入 error_log，并继续循环。这种写法和真正的嵌套事务在行为上非常接近：每个块相当于一个子事务，块内失败只回滚块内的修改。
不过，隐式保存点并不是免费的。每进入一个带 EXCEPTION 的块，PostgreSQL 都需要在内部维护保存点状态，这比普通代码块有更高的开销。如果循环次数很大，而且大部分记录都会成功，可以考虑用其他方式减少异常块的进入次数，或者接受这一成本。另外，EXCEPTION 块捕获所有异常时，如果异常是由于死锁或串行化失败等严重错误引起，只回滚到保存点并不一定能解决根本问题，生产环境中需要结合错误码 SQLSTATE 做更细粒度的处理。
三、实现可控的保存点栈，模拟多级嵌套事务
如果业务需要不止一层的嵌套，比如主事务中包含子事务，子事务中又包含自己的子事务，仅靠一个固定名称的 SAVEPOINT 是不够的。虽然 PostgreSQL 允许在同一个事务内创建多个保存点，但它们的管理需要开发者自行维护。我们可以通过一个栈结构来记录保存点名称，每次进入一个嵌套层就压入一个唯一名称，回滚或提交时弹出栈顶。这样就能模拟多级嵌套事务的语义。
在 PL/pgSQL 中可以使用数组来充当栈，也可以利用一个序列号生成器保证保存点名称不冲突。下面是一个简化示例，演示如何手动维护保存点栈：
DO $$
DECLARE
sp_stack TEXT[] := '{}';
sp_name TEXT;
step_failed BOOLEAN := false;
BEGIN
-- 第一层子事务
sp_name := 'sp_1';
sp_stack := sp_stack || sp_name;
EXECUTE 'SAVEPOINT ' || sp_name;
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;
-- 第二层子事务
sp_name := 'sp_2';
sp_stack := sp_stack || sp_name;
EXECUTE 'SAVEPOINT ' || sp_name;
UPDATE accounts SET balance = balance + 100 WHERE account_id = 2;
-- 模拟第二层失败
step_failed := true;
IF step_failed THEN
sp_name := sp_stack[array_length(sp_stack, 1)];
EXECUTE 'ROLLBACK TO SAVEPOINT ' || sp_name;
sp_stack := sp_stack[1:array_length(sp_stack, 1)-1];
ELSE
sp_name := sp_stack[array_length(sp_stack, 1)];
EXECUTE 'RELEASE SAVEPOINT ' || sp_name;
sp_stack := sp_stack[1:array_length(sp_stack, 1)-1];
END IF;
-- 第一层继续
UPDATE accounts SET balance = balance + 100 WHERE account_id = 3;
-- 第一层提交，释放保存点
sp_name := sp_stack[array_length(sp_stack, 1)];
EXECUTE 'RELEASE SAVEPOINT ' || sp_name;
sp_stack := sp_stack[1:array_length(sp_stack, 1)-1];
END;
$$;
上面的代码通过 TEXT 数组模拟保存点栈，进入每层子事务时生成唯一名称并执行 SAVEPOINT。当某个子事务失败时，取出栈顶名称执行 ROLLBACK TO SAVEPOINT，只撤销该层所做的修改；成功时则执行 RELEASE SAVEPOINT 释放该层保存点。需要注意，动态执行 SAVEPOINT 和 ROLLBACK TO SAVEPOINT 时，保存点名称必须符合 PostgreSQL 标识符规则，不能包含特殊字符，最好只使用字母、数字和下划线。
这种手动管理方式虽然灵活，但增加了代码复杂度。如果嵌套层次少，更推荐直接使用固定的保存点名称，或者把业务拆成多个函数，通过函数调用和异常捕获来隔离失败。PostgreSQL 没有提供类似 T-SQL 的 TRY CATCH 那样简单直接的嵌套事务语法，因此要根据实际场景权衡实现的必要性。
四、保存点回滚的锁释放与性能影响
很多开发者在模拟嵌套事务时容易忽略锁的问题。PostgreSQL 中的行级锁和表级锁在事务内获取后，通常要到事务结束才释放。但保存点回滚是一个例外：如果在保存点之后获取了某些锁，然后回滚到该保存点，这些在保存点之后获取的锁会被释放。这是因为保存点的回滚会撤销后续命令，锁的持有也随之失效。不过，保存点之前获取的锁依然继续持有，直到事务提交或回滚。理解这一点对并发环境下的死锁排查很有帮助。
举个例子，事务 T1 在保存点之前锁定了账户 A，在保存点之后又锁定了账户 B，然后回滚到保存点。此时账户 B 上的锁会释放，其他事务可以立即操作账户 B；但账户 A 的锁仍然由 T1 持有。如果另一个事务 T2 已经持有账户 B 的锁并等待账户 A，由于 T1 释放了账户 B 的锁并继续等待账户 A，死锁风险会降低。反之，如果回滚范围没有覆盖某个锁，锁会一直保留。因此，在设计保存点边界时，要考虑哪些资源需要在子事务失败后立即释放。
性能方面，保存点的主要开销来自事务状态的管理。每创建一个保存点，PostgreSQL 需要记录当前事务的指令位置和资源状态，以便后续回滚。频繁创建和释放保存点会增加内存消耗，也可能导致 WAL 写入量上升。尤其是 PL/pgSQL 的 EXCEPTION 块，每进入一次就会创建隐式保存点，如果循环百万次且每次都带 EXCEPTION，性能损耗会比较明显。建议在高并发写入路径上避免过度使用，改用批量校验或预先检查的方式减少异常触发。对于真正需要细粒度回滚的业务，可以通过基准测试评估保存点数量对吞吐量的影响，再决定是否采用。
PostgreSQL嵌套事务SAVEPOINT修改时间：2026-09-19 09:39:16