在PostgreSQL的的逻辑复制体系里，分区表因为其特殊的继承结构，常常让DBA在配置发布与订阅时感到困惑。逻辑复制是基于发布（publication）和订阅（subscription）实现的，发布端把预写日志（WAL）中符合条件的数据变更解析出来发送给订阅端。当一张表被定义为分区表时，它本身通常是一个不包含数据的父表，真实数据落在各个子分区（partition）中。如果不加任何过滤，把父表加入发布就意味着所有子分区的INSERT、UPDATE、DELETE都会被同步，这在数据量庞大且只需部分分区时会造成网络和存储的巨大浪费。
很多人在初次使用时会尝试用CREATE PUBLICATION的WHERE子句去过滤父表，但实际上PostgreSQL目前并不支持在分区父表上直接写行过滤条件来按子分区裁剪。系统要求如果要对分区表使用行过滤，必须保证所有子分区都有一致的过滤规则，否则会报错。这就引出了本文的核心问题：我们究竟该用哪种方式，才能精准地把分区表中的某一部分数据通过逻辑复制同步出去，而不动其余部分。
分区表加入发布的底层行为解析
当我们执行ALTER PUBLICATION把分区父表加入发布列表时，PostgreSQL内部会遍历它的所有子分区，把每一个子分区都隐式地注册为发布对象。从机制上看，逻辑解码插件（如pgoutput）在读取WAL时，拿到的是子分区上的真实元组，父表只是路由和定义的容器。这意味着如果你不想同步某些历史分区，最直白的办法就是不要将父表整体加入，而是手动把需要的子分区作为独立表加入发布。
例如，我们有一个名为orders的列表分区表，按年份分为orders_2023、orders_2024、orders_2025。如果只需要同步2024和2025，就避开ALTER PUBLICATION … ADD TABLE orders这种写法，改为分别添加子分区。这样发布端只会为这两张子分区建立复制标识和WAL抽取任务，历史库orders_2023完全不会产生逻辑复制流量。
需要注意的是，这种手动添加子分区的方式要求子分区本身是普通堆表（或自身不再有子分区）。如果子分区又是分区表，则需要继续下钻。另外，在PG14及之后版本，如果父表加了PUBLICATION，再单独排除某个子分区是不支持的，因此规划发布结构要在最开始就确定好粒度，避免后期反复调整导致复制槽积压。
使用行级过滤配合分区键的实践方案
如果业务上希望“用一个发布就搞定”，且过滤条件刚好能和分区键对应，那么可以为父表设置WHERE子句，但前提是每个子分区都能满足该条件。举例来说，orders表以order_date做范围分区，我们可以写CREATE PUBLICATION orders_pub FOR TABLE orders WHERE (order_date >= '2024-01-01')。由于所有子分区的order_date都落在各自区间内，只要2023分区的所有行都不满足该条件，发布端在解码时就会自动丢弃那些不匹配的元组。
不过这里有个陷阱：行过滤是在WAL解码阶段做的，不符合条件的旧分区虽然不会被发给订阅端，但发布端仍然要读取这些分区的WAL并做判断，CPU开销并没有完全消失。因此对于明确不想要的分区，优先用“只发布指定子分区”的方案更彻底。下面给出一段创建带过滤发布的示例代码：
-- 创建仅包含近期数据的发布，依托分区键过滤 CREATE PUBLICATION orders_recent_pub FOR TABLE orders_2024, orders_2025 WITH (publish = 'insert, update, delete, truncate'); -- 如果确需用父表加WHERE，确保子分区无矛盾 -- CREATE PUBLICATION orders_pub FOR TABLE orders -- WHERE (order_date >= '2024-01-01');
在订阅端，对应的订阅者只需要正常CREATE SUBSCRIPTION指向该发布即可。如果发布端是手动列子分区，订阅端表结构也要保持一致，即也建好同名的子分区，否则初始同步会报关系不存在。建议用pg_dump仅导出需要的子分区定义到订阅库，降低结构不一致风险。
监控与避坑：复制槽和DDL的影响
精准过滤分区表后，最容易忽视的是复制槽（replication slot）的堆积问题。因为逻辑复制槽会保留发布端所有未被订阅确认的消费位点，若某个子分区突然写入大量不满足过滤条件但仍被解码的数据（比如用了父表WHERE但旧分区有零星更新），WAL就会卡在槽里。可用pg_replication_slots视图观察active和restart_lsn的滞后情况。
另一个坑是分区表的DDL操作。当你用ALTER TABLE ATTACH PARTITION把新分区挂到父表下时，如果发布里是父表且带过滤，新分区会自动继承发布属性；但如果你是手动列子分区的方式，新分区不会自动加入，必须再跑一次ALTER PUBLICATION … ADD TABLE。这种非自动同步常常导致“明明插了数据订阅端却没有”的错觉，排查时要先确认子分区是否在pg_publication_tables里。
此外，TRUNCATE在分区表上的传播也要小心。若发布定义了publish包含truncate，对父表做TRUNCATE会下发到所有子分区，订阅端若只建了部分子分区就会报错。因此建议对分区表复制关闭truncate发布，或确保订阅端结构与发布端严格对称。通过这些细节把控，PostgreSQL逻辑复制过滤分区表就能做到既精准又稳定。
PostgreSQL逻辑复制分区表修改时间：2026-08-13 21:33:30