PL/pgSQL存储过程是否为独立事务？调用链锁生效范围如何？

核心结论 #

你描述的场景下锁的生命周期和存储过程所属事务边界直接绑定，具体规则如下：

1. 默认状态下，嵌套调用的存储过程全程属于同一个事务上下文
   你给出的A调用B、再调用C的示例，如果没有显式写事务控制语句，整个调用链运行在同一个事务里，只有当最外层的A执行完成，整个事务提交/回滚时，事务级资源才会释放。
   你用到的pg_advisory_xact_lock是事务级咨询锁，天然和当前事务绑定，所以这种默认情况下你在B里加的锁，会一直持有到A执行结束、整个事务提交才释放，不会在C执行前自动释放。
2. 要实现B执行完就释放锁，有两种可行方案

• 方案1：显式控制事务提交
  PostgreSQL的存储过程支持内部显式事务控制，你可以在A里调用完B之后主动加COMMIT语句提交事务，此时B里申请的事务级咨询锁会随事务提交直接释放，之后再调用C即可。需要注意该方案要求B的业务逻辑允许单独提交，不会和后续C的逻辑产生事务一致性关联。
  示例逻辑：

CREATE OR REPLACE PROCEDURE A()
LANGUAGE plpgsql
AS $$
BEGIN
  CALL B(); -- B内部申请pg_advisory_xact_lock
  COMMIT; -- 提交事务，B里的事务级锁直接释放
  CALL C();
END;
$$;

• 方案2：改用会话级咨询锁主动释放
  如果需要B和C的逻辑在同一个大事务里执行，不允许中途提交，可以不用拆分事务，也不用拆分存储过程，直接把pg_advisory_xact_lock替换成会话级咨询锁pg_advisory_lock，在加锁的代码片段执行完成后主动调用pg_advisory_unlock释放锁即可，不需要等待事务结束。
  示例逻辑：

-- 加锁的业务片段内部逻辑
PERFORM pg_advisory_lock(自定义锁键值);
-- 执行需要加锁保护的业务代码
-- ...
-- 执行完立刻解锁
PERFORM pg_advisory_unlock(自定义锁键值);

内容的提问来源于stack exchange，提问作者debuggrl