PostgreSQL逻辑复制从10版本开始提供发布与订阅机制，发布端可以通过WHERE条件决定哪些行变更被发送到订阅端。这个过滤表达式并不是简单存在配置文件里，而是作为系统目录pg_publication_rel中的prqual字段保存。执行物理备份或逻辑备份时，发布定义是否一起恢复，取决于备份工具和参数。恢复之后如果过滤策略丢失，逻辑复制会退化成整表推送，给下游带来脏数据和额外写入压力。本文从系统目录层面分析过滤策略如何存储，结合备份恢复实战说明保持过滤策略有效的方法。
一、逻辑复制过滤策略的存储与作用机制
PostgreSQL的发布对象可以针对所有表，也可以只针对部分表。当发布只包含部分表时，每张被发布的表都会在系统目录pg_publication_rel中记录一条映射关系。行过滤表达式以pg_node_tree类型保存在prqual字段中，列过滤列表则保存在prattrs字段里。逻辑解码进程在读取WAL并生成变更集时，会根据这些表达式决定哪些行和哪些列进入复制流。过滤动作发生在发布端，订阅端接收到的已经是过滤之后的结果。
可以通过下面的SQL查看发布端当前配置的行过滤和列列表。查询结果中的pg_get_expr函数会把内部的表达式树还原成可读的WHERE条件。
SELECT p.pubname,
c.relname AS table_name,
pg_get_expr(pr.prqual, pr.prrelid) AS row_filter,
pr.prattrs AS column_list
FROM pg_publication p
JOIN pg_publication_rel pr ON pr.prpubid = p.oid
JOIN pg_class c ON c.oid = pr.prrelid
WHERE p.pubname = 'pub_orders';
行过滤表达式可以引用表中的普通列，也可以调用自定义函数。例如一个发布可以只推送状态为active且区域为cn的订单，逻辑解码阶段在执行表达式时会调用相应的比较操作和函数。如果表达式引用的函数在备份恢复后缺失，或者函数行为发生变化，过滤策略虽然看起来还在，但实际执行会报错，逻辑复制会中断。因此过滤策略不只是文本，还包括它依赖的数据库对象。
还需要注意一个重要限制：行过滤只对逻辑复制开始后的增量变更生效，不会影响订阅初始同步阶段的数据复制。使用CREATE SUBSCRIPTION并启用copy_data时，PostgreSQL会使用COPY方式复制整个表的数据，此时发布端的行过滤并不会被应用。恢复后如果重新创建订阅时省略了copy_data = false，订阅端可能先收到一批未过滤的全量数据，后续增量数据又按照过滤条件推送，造成数据不一致的假象。
二、备份恢复过程中过滤策略的保留与丢失点
逻辑备份工具pg_dump默认会导出发布定义，包括发布名称、发布针对的表、行过滤表达式以及列列表。转储文件中会生成对应的CREATE PUBLICATION语句。因此使用pg_dump备份数据库并恢复到新实例时，发布定义通常是保留的。但如果备份命令中使用了--no-publications参数，或者手动只选择导出业务表，发布定义就会丢失。
下面的命令演示了如何使用逻辑备份同时保留发布定义，并跳过订阅和权限相关对象的导出，以便恢复到新环境时拥有更大的调整空间。
pg_dump -h source_host -U postgres -Fc -d source_db \ --no-subscriptions --no-owner --no-privileges \ -f logical_backup.dump
恢复时使用pg_restore即可重新创建发布定义。目标库需要先创建好对应的数据库和角色，然后再恢复备份文件。
pg_restore -h target_host -U postgres -d target_db \ --no-owner --no-privileges logical_backup.dump
物理备份场景与逻辑备份不同。pg_basebackup复制的是整个数据目录，发布定义所在的系统目录会被完整保留。但物理备份通常不会包含活跃的逻辑复制槽状态，复制槽中的restart_lsn和confirmed_flush_lsn等进度信息不会跟着备份走。恢复到新节点后，逻辑复制槽需要重新创建，订阅端也需要重新指向恢复后的发布端。如果只恢复了数据目录，却没有同步处理复制槽和订阅，逻辑复制链路不会自动恢复工作。
另外，逻辑备份不会转储订阅定义。订阅信息保存在pg_subscription系统目录中，属于实例级连接配置，不在某个数据库的转储范围内。因此恢复过滤策略时，发布端的发布定义可以通过pg_restore恢复，但下游的订阅需要手动创建。很多恢复后复制不生效的问题，并不是发布定义丢了，而是订阅没有被重建。
三、恢复后验证与重建过滤策略的实操步骤
恢复完成后的第一步是验证发布定义是否完整。不要只看发布名称是否存在，还要确认行过滤表达式和列列表与源端一致。可以在源端和目标端分别执行查询pg_publication_rel的SQL，对比row_filter和column_list的结果。如果目标端prqual字段为空，说明只有表级发布而没有行过滤，这时必须手动重建发布。
SELECT p.pubname,
c.relname,
pg_get_expr(pr.prqual, pr.prrelid) AS row_filter
FROM pg_publication p
JOIN pg_publication_rel pr ON pr.prpubid = p.oid
JOIN pg_class c ON c.oid = pr.prrelid
ORDER BY p.pubname, c.relname;
如果发现目标端发布定义丢失或者内容不完整，可以手动删除并重新创建。创建时要注意列列表的语法，列列表放在表名后面的括号中，行过滤放在WHERE子句中。例如只发布订单号、状态和区域三列，并且只推送状态为active的行。
CREATE PUBLICATION pub_orders FOR TABLE orders (order_id, status, region) WHERE (status = 'active') WITH (publish = 'insert,update,delete');
当发布端已经存在发布但需要修改行过滤条件时，可以使用ALTER PUBLICATION语句。下面的例子增加了一个金额大于100的条件，注意SQL中大于号在HTML代码块中需要转义。
ALTER PUBLICATION pub_orders SET TABLE orders WHERE (status = 'active' AND amount > 100);
发布定义确认无误后，在目标端创建逻辑复制槽并重建订阅。为了验证过滤策略是否真正生效，建议先使用copy_data = false创建订阅，避免全量数据干扰判断。订阅端需要先具备与发布表结构一致的目标表。
CREATE SUBSCRIPTION sub_orders CONNECTION 'host=source_host port=5432 user=rep password=secret dbname=source_db' PUBLICATION pub_orders WITH (copy_data = false, enabled = true);
创建订阅后，在发布端插入两条测试数据，一条满足过滤条件，另一条不满足。等待复制延迟过后，检查订阅端是否只收到了满足条件的那一条。如果两条都到达，说明行过滤没有生效，需要检查发布定义是否被正确恢复。
INSERT INTO orders (order_id, status, region, amount) VALUES (1001, 'active', 'cn', 300); INSERT INTO orders (order_id, status, region, amount) VALUES (1002, 'active', 'us', 500);
四、常见故障与排查思路
第一种常见故障是恢复后逻辑复制持续推送整表数据，过滤策略看起来失效了。排查时先确认发布端发布定义是否使用FOR ALL TABLES。如果发布定义是这样创建的，那么后期通过ALTER PUBLICATION添加的行过滤可能并未生效，因为FOR ALL TABLES的发布不支持针对单表设置行过滤。此时需要将发布改为仅包含指定表，再对指定表设置行过滤条件。
第二种故障是逻辑复制启动时报错publication does not exist。这种错误通常出现在只恢复了业务表数据，而发布定义没有被恢复的场景中。需要从逻辑备份中单独提取发布定义，或者直接根据源端pg_publication和pg_publication_rel的查询结果手动生成并执行CREATE PUBLICATION语句。
第三种故障是过滤表达式引用的函数不存在。行过滤表达式中如果调用了一个自定义函数，例如is_valid_order()，而目标库中还没有恢复这个函数，逻辑解码会报错并停止发送变更。恢复时应该先恢复函数、扩展和操作符等依赖对象，再创建发布，顺序不能颠倒。如果已经创建了发布，可以删除发布后重新创建，或者在目标库补齐函数后重启逻辑复制进程。
第四种故障与初始同步有关。恢复后新建订阅时，如果默认开启了全量同步，发布端的行过滤不会应用在初始数据复制阶段，导致订阅端先出现一批未过滤的历史数据。处理办法是创建订阅前先手动在目标端导入历史数据，然后用copy_data = false创建订阅，让逻辑复制只处理增量变更。如果初始同步已经开始，只能清理目标表数据后重新创建订阅。
过滤策略能否在备份恢复后继续生效，取决于发布定义是否保留、依赖对象是否完整、复制链路是否重新建立。只要理解了pg_publication_rel中表达式存储机制，并在恢复后按顺序验证发布、复制槽和订阅，就能避免逻辑复制过滤策略在灾难恢复场景中失效。
PostgreSQL逻辑复制过滤策略备份恢复修改时间：2026-08-23 12:33:52