逻辑复制是PostgreSQL中一项强大的数据同步能力，它基于WAL解码将数据变化以逻辑形式发送给订阅者。在实际场景中，一张业务表可能同时服务于多个下游系统，这些系统往往只需要其中一部分数据。例如订单表里既有已支付订单也有未支付订单，而下游的分析系统只关心已支付订单。默认情况下，逻辑复制会把整张表的全部数据变化推送给订阅端，这不仅浪费网络带宽，还会给订阅端带来不必要的存储压力和计算开销。好在PostgreSQL从10版本开始引入了行过滤（Row Filter）能力，允许在发布端为表定义行级条件，从而只发布满足条件的行。

行过滤的核心优势在于它把数据筛选的工作前移到了发布端。一旦在发布端定义了过滤条件，WAL解码过程中只会提取出符合条件的INSERT、UPDATE和DELETE操作，那些不符合条件的行变化根本不会进入逻辑复制流。对于初始数据同步，也就是创建订阅时触发的COPY阶段，同样会应用行过滤，只把当前表里满足条件的快照数据复制过去。这一点对首次搭建下游系统尤其有用，可以避免把大量无关历史数据灌入订阅端。当然，使用行过滤也意味着后续如果过滤条件发生变化，必须手动处理订阅端已有数据的同步策略，这部分内容稍后会展开讨论。

发布端行过滤的基本语法与实现机制

在PostgreSQL中，创建发布时可以针对具体表使用FOR TABLE ... WHERE子句来声明行过滤条件。语法结构如下：

CREATE PUBLICATION pub_filtered FOR TABLE orders WHERE (status = 'paid' AND amount > 100);

上面的语句会创建一个名为pub_filtered的发布，它只把orders表中status字段等于paid且amount字段大于100的行纳入逻辑复制范围。注意WHERE条件必须放在圆括号内，并且条件表达式必须返回布尔类型。如果一个发布包含多张表，可以分别给每张表指定不同的过滤条件，也可以对某些表不设置过滤条件。命令行中的>代表大于号，在SQL语句中也可以直接写成>，但为了规避HTML解析问题，在代码块中使用了实体转义。

行过滤条件在WAL解码时由walsender进程进行评估。每一行变化都会在发布端被重新计算一次该行是否满足条件。对于INSERT来说，直接判断新行的值是否通过过滤即可；对于UPDATE，需要分别判断旧行和新行，只有新行满足条件才会发布UPDATE；如果旧行满足条件而新行不满足条件，则会发出一条DELETE操作，让订阅端把该行删除；如果旧行不满足条件而新行满足条件，则发出一条INSERT操作。这个行为与常规逻辑复制保持一致，消费者无需感知发布端的过滤逻辑。DELETE操作则只检查旧行是否满足条件，满足才发送。

需要注意的是，行过滤条件中不能使用易变函数（volatile function），比如random()、now()等，因为WAL解码可能在流复制节点上发生，且不同时间点评估结果可能不一致。官方文档建议只使用不可变函数（immutable function）以及等值比较。如果确实需要基于时间过滤，建议使用常量或者由应用层保证一致性。此外，过滤条件不能引用系统列（如ctid、xmin等），也不能包含子查询或聚合函数。

修改行过滤条件与订阅端影响

随着业务变化，可能需要调整已有的行过滤规则。例如原本只同步paid状态的订单，后来要求也同步refunded状态。这时可以使用ALTER PUBLICATION语句来修改表级的过滤条件：

ALTER PUBLICATION pub_filtered SET TABLE orders WHERE (status IN ('paid', 'refunded') AND amount > 100);

这条命令会替换orders表旧的过滤条件。修改成功后，发布端将在后续的WAL解码中应用新条件。但有一个关键点必须明确：对于已经存在的订阅，修改过滤条件并不会自动触发一次全量重新同步。这意味着订阅端数据库可能仍然保留着以前过滤条件下同步过来的行，而新过滤条件下应该新增的行（比如status从pending变为refunded的历史数据）也不会自动补发，除非它们之后发生了新的数据变更。要让订阅端和发布端保持一致，通常需要手动处理，比如重新创建订阅、使用逻辑复制的初始化功能，或者通过其他ETL手段补齐数据。

另一个容易被忽略的问题是REPLICA IDENTITY设置。逻辑复制在发送UPDATE或DELETE时，需要识别行的唯一标识。如果表有主键或非空唯一索引，默认REPLICA IDENTITY会在WAL中记录这些关键列的值，足以定位到具体行。但某些业务表可能没有主键，或者主键列不在行过滤的判定逻辑中。此时，如果过滤条件涉及到的列恰好不属于唯一标识，当该列的值发生变化时，发布端可能无法正确识别更新前的行，从而导致复制失败。解决办法是为表设置ALTER TABLE ... REPLICA IDENTITY FULL，让整行数据都作为标识。代价是WAL记录量会显著增大，对写入性能有一定影响。因此，在设计发布表结构时，尽量确保表有稳定的主键，并且主键列不参与过滤条件中的变化逻辑。

行过滤的实践配置与常见问题排查

下面通过一个完整的示例演示如何搭建带行过滤的逻辑复制环境。假设源库有一张orders表，包含id、customer_id、status、amount和created_at列。我们先创建发布：

-- 源库执行
CREATE TABLE orders (
    id serial PRIMARY KEY,
    customer_id int NOT NULL,
    status text NOT NULL,
    amount numeric(10,2) NOT NULL,
    created_at timestamptz NOT NULL DEFAULT now()
);
INSERT INTO orders (customer_id, status, amount) VALUES
(1, 'paid', 150.00),
(2, 'pending', 80.00),
(3, 'paid', 200.00),
(4, 'refunded', 120.00);
CREATE PUBLICATION pub_orders FOR TABLE orders WHERE (status = 'paid');

然后在订阅端创建相同的表结构（不需要数据），并创建订阅：

-- 订阅端执行
CREATE TABLE orders (
    id serial PRIMARY KEY,
    customer_id int NOT NULL,
    status text NOT NULL,
    amount numeric(10,2) NOT NULL,
    created_at timestamptz NOT NULL DEFAULT now()
);
CREATE SUBSCRIPTION sub_orders CONNECTION 'host=127.0.0.1 port=5432 dbname=source user=repl_user password=secret' PUBLICATION pub_orders;

订阅创建完成后，订阅端只会同步到两条status为paid的记录，而pending和refunded的记录不会被复制。如果此时源库执行UPDATE orders SET status='paid' WHERE id=2，那么这条pending订单会变为paid，发布端会向订阅端发送一条INSERT操作，将id=2的行数据同步过去。同理，如果把id=1的paid改为refunded，订阅端会收到DELETE操作，把该行从订阅端表中删除。这一系列行为完全透明，下游应用不需要做任何特殊处理。

在实际运维中，常见的错误包括：创建发布时忘记加圆括号导致语法错误；在过滤条件中使用了不支持的操作符；修改发布过滤条件后没有重新初始化订阅，导致数据不一致；以及没有为无主键表设置REPLICA IDENTITY FULL，导致更新操作报错。还有一个容易踩的坑是分区表：如果对分区根表设置行过滤条件，只有根表本身会被过滤，各分区不会自动继承过滤规则，需要分别为每个分区添加过滤条件。否则逻辑复制可能会把分区中所有行都发布出去。建议在使用行过滤前先在测试环境充分验证，特别是涉及分区表和无主键表的情形。

行过滤功能是PostgreSQL逻辑复制中一个非常实用的特性，它帮助开发者在数据源头就做好分发控制，显著降低下游系统的资源消耗。只要理解了它的工作机制和限制条件，就能在多种数据同步架构中灵活运用。无论是做读写分离、跨库同步还是数据仓库抽取，发布端行过滤都能提供精准、高效的行级控制能力。