PostgreSQL创建策略需ACCESS EXCLUSIVE锁的原因及并发解决方法

为什么创建策略需要ACCESS EXCLUSIVE锁？ #

PostgreSQL的行级安全（RLS）策略属于表的元数据范畴，创建或修改策略时，数据库必须保证所有针对该表的活跃查询都能看到一致的规则集——如果允许并发执行SELECT和策略修改，可能出现同一个查询过程中策略突然变更，导致返回结果不符合预期，甚至引发安全风险（比如查询中途策略放宽，意外泄露数据）。

为了彻底避免这种一致性问题，PostgreSQL会给CREATE POLICY命令分配ACCESS EXCLUSIVE锁，这是表级锁中最严格的类型，会阻塞所有针对该表的读写操作，直到策略创建完成、锁释放为止。这就是你的命令被role1的活跃SELECT卡住的原因。

如何规避锁实现并发执行？ #

1. 利用角色继承间接授权（最优方案） #

既然你要给role2开放全表SELECT权限（USING (TRUE)），可以绕过直接创建策略的方式，改用角色继承：

• 先创建一个专门用于全表查询的角色（如果还没有）：

  CREATE ROLE role_select_all;
  

• 给这个角色创建对应的SELECT策略（只需执行一次，后续无需重复操作）：

  CREATE POLICY policy_select_all ON {table} AS PERMISSIVE FOR SELECT TO role_select_all USING (TRUE);
  

• 把role2加入这个角色，这个操作不需要对目标表加ACCESS EXCLUSIVE锁，完全不会阻塞正在运行的SELECT：

  GRANT role_select_all TO role2;
  

这样role2就能继承到全表查询的权限，整个过程可以和role1的活跃查询并发执行。

2. 选择业务低峰期执行 #

如果必须直接创建策略，只能等业务低峰期操作——此时没有活跃的SELECT查询，CREATE POLICY命令可以快速获取锁并执行，不会影响正常业务。

3. 终止长时间运行的查询（应急方案） #

如果遇到命令长时间卡住的紧急情况，可以通过系统视图查看并终止阻塞锁的查询：

-- 查询目标表的活跃SELECT进程
SELECT pid, query FROM pg_stat_activity WHERE datname = '你的数据库名' AND relname = '{table}' AND state = 'active';
-- 终止指定进程（替换pid为实际进程ID）
SELECT pg_cancel_backend(pid);

注意：这个方法会中断业务查询，仅适合紧急场景使用。

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