PostgreSQL的行安全策略与逻辑复制行过滤常被混淆。前者的核心是在数据库会话内对查询结果做裁剪，后者则是发布端决定哪些变更需要流向订阅端。本文围绕一个问题展开：当一张表同时启用了RLS和逻辑复制时，订阅端收到的数据到底是RLS裁剪后的子集，还是表中实际存在的全部行？答案取决于发布定义中是否显式写入了行过滤条件。若没有显式过滤，RLS通常不会成为复制链路的默认守门人。
一、逻辑复制行过滤与RLS的作用边界
PostgreSQL从版本15开始支持在发布命令中为表添加行过滤条件。语法形式大致如下：
CREATE PUBLICATION pub_orders FOR TABLE orders WHERE (status = 'active');
这个WHERE子句会在发布端对每一行变更进行评估。初始数据同步时，只有满足条件的行会被复制到订阅端；增量同步期间，INSERT、UPDATE、DELETE都会根据条件判断是否需要向订阅端发送对应的事件。行过滤的好处是让复制链路能够按业务维度分发数据，例如不同租户的表数据只流向各自的订阅库。
而行安全策略则工作在不同的层面。RLS通过ALTER TABLE ... ENABLE ROW LEVEL SECURITY启用，并用CREATE POLICY定义USING和WITH CHECK表达式。它主要作用于普通SQL命令执行阶段，限制哪些行可以被SELECT、UPDATE或DELETE访问。它的保护和用户会话上下文紧密相关，比如current_user、current_setting产生的动态条件。逻辑复制的初始快照和WAL解码过程并不会自动套用这些策略。换句话说，即使表上已经启用了RLS，只要发布定义中没有对应的行过滤条件，订阅端仍然可能接收到RLS本来要隐藏的行。
这种差异在安全上很关键。比如一个多租户系统在应用层依赖RLS隔离租户数据，但管理员为了做报表或数据同步，把整张表加入逻辑复制发布。如果仅依赖RLS来限制复制，那么复制用户只要以表所有者或具备BYPASSRLS权限的身份连接，就会绕过策略；即使普通用户发起复制，RLS也可能因为复制连接的用户上下文不确定而不会按业务会话的方式生效。因此必须把需要的行过滤条件显式地放到发布定义里。
二、把行安全策略转换为发布过滤条件
最典型的场景是租户隔离。假设有一张订单表：
CREATE TABLE orders (
id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
tenant_id integer NOT NULL,
amount numeric(12,2) NOT NULL,
status text NOT NULL
);
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_policy ON orders
USING (tenant_id = current_setting('app.tenant_id')::integer);
这个RLS策略在普通业务查询中会根据会话参数app.tenant_id来过滤行。但在逻辑复制发布中，不能直接把这种动态条件搬过去。PostgreSQL文档对行过滤表达式有明确约束：它只能使用被发布表的列，不能包含子查询、用户自定义函数、系统列，而且所有内置函数必须是immutable类型。current_setting属于stable函数，其返回值会随会话上下文变化，无法保证复制过程的确定性，因此不会被行过滤接受。
解决办法通常是把动态RLS条件改写成静态条件。例如需要为租户ID为1的数据创建独立发布时，可以这样写：
CREATE PUBLICATION pub_orders_tenant_1 FOR TABLE orders WHERE (tenant_id = 1);
如果租户数量很多，可以为每个租户创建单独的发布，或者使用分区表把租户数据分散到不同分区，再按分区进行发布。分区方案还能带来更清晰的数据边界，订阅端可以选择只订阅特定分区，减少发布端计算过滤表达式的开销。对于current_user这种身份条件，同样无法直接迁移，需要在数据模型上引入物理列来承载过滤键，避免复制链路依赖会话状态。
如果RLS条件比较复杂，例如包含OR、类型转换或内置函数，可以先在SQL查询中验证改写后的表达式能否正常使用索引。发布过滤条件会直接影响初始快照的查询计划，若过滤列没有索引，初始同步可能会退化为全表扫描。把tenant_id这样的过滤列建上索引，对发布端和普通查询都有好处。
三、初始快照与增量同步阶段的行为差异
行过滤在初始快照阶段表现为一个受限的SELECT。订阅端第一次连接时，发布端会执行类似COPY (SELECT * FROM orders WHERE tenant_id = 1) TO STDOUT的操作，只把匹配行送到订阅端。这个阶段相对直观，需要注意的只是过滤条件的性能。如果发布表中的数据量大，且过滤列没有索引，初始同步时间会明显拉长。
增量同步阶段的行为更复杂。对于INSERT，判断条件比较直接：新行满足过滤条件就发送INSERT。对于DELETE，旧行满足条件才发送DELETE。UPDATE则需要同时考察旧行和新行。具体规则是：如果旧行满足条件而新行不满足，订阅端会收到一个DELETE；如果旧行不满足条件而新行满足，订阅端会收到一个INSERT；如果旧行和新行都满足条件，订阅端收到UPDATE；如果两者都不满足，则不发送任何事件。
这意味着一条租户数据从tenant_id等于1更新为等于2时，针对tenant_id等于1的发布会向订阅端发送DELETE，而不是UPDATE。订阅端如果没有正确处理这种拆分事件，可能导致数据残留或约束冲突。例如订阅端表上有外键引用，DELETE可能因为子表记录未同步过去而失败。因此，在设计逻辑复制过滤场景时，要提前确认关联表是否也需要一同发布，并保持过滤条件的一致性，否则会出现半拉子数据。
另一个容易忽略的问题是初始快照和增量同步之间的切换。初始快照是在一个一致性快照下复制全部匹配行，但切换过程中如果源库继续写入，新产生的变更会暂存在复制槽中。如果过滤条件在切换前后发生变化，比如管理员修改了发布定义，可能会导致订阅端缺少部分数据。因此发布过滤条件应尽量保持稳定，不要在运行中频繁修改。
四、权限、性能与安全权衡
创建发布和使用行过滤需要相应的权限。在PostgreSQL中，创建发布需要当前数据库的CREATE权限，而要对表添加行过滤，用户还必须具备该表的SELECT权限。复制连接用户则需要REPLICATION权限，并且对发布中的所有表有SELECT权限。如果一个复制用户受RLS限制，初始快照查询可能实际返回的行比预期更少，但增量WAL解码仍会读取所有已发生变更。这种不对称会让订阅端数据难以预测，因此最好为复制用户赋予BYPASSRLS属性，同时把真正的过滤责任交给发布定义。
性能方面，行过滤表达式在增量解码时会对每一行变更进行计算。简单的等值条件开销很低，但如果使用复杂的函数或类型转换，就会增加CPU负担。过滤列上有B-tree索引可以加速初始快照，但对WAL解码产生的单行判断帮助有限。高写入负载下，建议保持过滤表达式简单，避免使用不必要的类型转换或字符串处理。
安全性上，行安全策略和逻辑复制行过滤应被视为两套独立的控制机制。RLS适合控制在线用户的会话级可见性，而逻辑复制行过滤负责控制数据离开源库的边界。两者可以结合使用，但不能互相替代。自动化生成发布定义时，可以从RLS策略中提取静态条件，但必须经过人工确认，确保动态会话参数已经被替换为明确的过滤值。否则一旦复制链路打通，看似有RLS保护的数据可能静默地泄露到订阅端。
总的来说，PostgreSQL的逻辑复制不会自动继承RLS条件。要实现行级安全的数据发布，必须在发布命令中显式编写行过滤表达式。理解这条边界，并针对初始快照和增量同步分别做好测试，才能在享受逻辑复制灵活性的同时守住数据安全。
PostgreSQL逻辑复制行级安全策略行过滤修改时间：2026-09-28 02:16:47