4、事务回滚机制：SAVEPOINT与子事务、ROLLBACK TO SAVEPOINT、异常处理中的回滚策略

在异步任务编排中，单个任务单元（如批量数据同步、多步骤ETL）往往包含多个可独立回滚的操作步骤。PostgreSQL 通过 SAVEPOINT 与 子事务 机制，允许在事务内部设置保存点，实现部分回滚，从而避免因单一步骤失败而废弃整个事务。本章深入剖析保存点的创建、回滚与释放，并结合异常处理场景给出最佳回滚策略。

4.1 子事务与SAVEPOINT核心概念

子事务是 PostgreSQL 事务模型中的逻辑嵌套单元，通过 SAVEPOINT 定义。一个事务内可以定义多个保存点，形成树状或线性结构。子事务的提交与回滚不会影响外层事务的最终状态，直到外层事务提交或回滚。

4.2 SAVEPOINT与ROLLBACK TO SAVEPOINT实战

以下示例展示在异步任务中，如何利用保存点实现部分回滚：

BEGIN;

-- 步骤1：插入主记录
INSERT INTO async_jobs (job_id, status) VALUES (1001, 'running');

-- 设置保存点A
SAVEPOINT sp_after_main;

-- 步骤2：插入子任务记录（可能失败）
INSERT INTO async_subtasks (job_id, subtask_id, payload)
VALUES (1001, 1, '{"action":"sync_user"}');

-- 步骤3：模拟异常（例如违反唯一约束）
-- 假设此处发生错误，回滚到保存点A
ROLLBACK TO SAVEPOINT sp_after_main;

-- 此时步骤2的插入被撤销，步骤1的插入仍然有效
-- 步骤4：重试或跳过子任务
INSERT INTO async_subtasks (job_id, subtask_id, payload)
VALUES (1001, 2, '{"action":"sync_order"}');

-- 释放保存点（可选）
RELEASE SAVEPOINT sp_after_main;

COMMIT;

执行流程说明：

• 保存点设置：在关键步骤后设置保存点，作为回滚锚点。
• 部分回滚：ROLLBACK TO SAVEPOINT 仅撤销保存点之后的变更，保存点之前的变更（如主记录插入）不受影响。
• 保存点释放：RELEASE 删除保存点，释放子事务ID，但不影响数据。

4.3 异常处理中的回滚策略

在 PL/pgSQL 或应用层异步任务编排中，异常处理与保存点结合使用，可以实现精细化的错误恢复。以下是三种典型策略：

以下展示 PL/pgSQL 中使用保存点实现细粒度回滚的典型模式：

CREATE OR REPLACE FUNCTION process_async_batch(batch_id INT)
RETURNS VOID AS $$
DECLARE
  subtask RECORD;
BEGIN
  -- 外层事务：记录批次开始
  INSERT INTO batch_log (batch_id, status) VALUES (batch_id, 'started');

  FOR subtask IN SELECT * FROM async_subtasks WHERE batch_id = batch_id LOOP
    -- 每个子任务设置独立保存点
    SAVEPOINT sp_subtask;

    BEGIN
      -- 执行子任务逻辑
      PERFORM execute_subtask(subtask.id);

      -- 成功则释放保存点
      RELEASE SAVEPOINT sp_subtask;
    EXCEPTION
      WHEN OTHERS THEN
        -- 回滚到子任务保存点，撤销该子任务的所有变更
        ROLLBACK TO SAVEPOINT sp_subtask;
        -- 记录失败日志，继续下一个子任务
        INSERT INTO error_log (subtask_id, error_msg)
        VALUES (subtask.id, SQLERRM);
    END;
  END LOOP;

  -- 更新批次状态
  UPDATE batch_log SET status = 'completed' WHERE batch_id = batch_id;
END;
$$ LANGUAGE plpgsql;

4.4 子事务与MVCC可见性

子事务的提交与回滚直接影响 MVCC 快照的可见性规则：

• 子事务提交：子事务内的变更在父事务提交后，才对其他会话可见。
• 子事务回滚：子事务内的变更立即对当前事务不可见，但物理行版本（dead tuple）仍存在于页面中，直到父事务提交或回滚后才被清理。
• 子事务ID膨胀：大量未提交的子事务会导致 pg_subtrans 目录膨胀，影响 VACUUM 效率。异步任务中应避免在长事务内创建过多保存点。

4.5 保存点与锁的交互

回滚到保存点不会释放该保存点之后获取的锁。锁的释放时机取决于外层事务的提交或回滚。在异步任务中，如果子任务持有行级锁或表级锁，即使回滚到保存点，锁仍然保持，直到外层事务结束。

4.6 保存点使用性能基准

以下数据基于 PostgreSQL 16 在异步批量任务场景下的测试结果（1000 条子任务，每条子任务设置一个保存点）：

4.7 最佳实践总结

• 保存点命名规范：使用有意义的名称（如 sp_subtask_<id>），便于调试和日志追踪。
• 及时释放：成功子任务后立即 RELEASE SAVEPOINT，避免子事务ID堆积。
• 控制数量：单个事务内保存点数量建议不超过 64 个，超过时考虑拆分为多个短事务。
• 锁管理：回滚到保存点后，显式释放不再需要的锁（如 pg_advisory_unlock），防止死锁。
• 异常日志：在异常处理块中记录 SQLERRM 和 GET STACKED DIAGNOSTICS 信息，便于事后分析。
• 测试覆盖：在开发环境模拟保存点回滚场景，验证数据一致性和锁释放行为。