PostgreSQL逻辑复制的核心机制是从WAL中解码行级变更，而临时表在PostgreSQL中不会产生可供复制的WAL记录，因此临时表数据天然不会进入逻辑复制流。但在日常运维中，同名遮蔽、发布范围配置不当或订阅端存在临时表等问题，仍可能让人误以为临时表被复制或引发复制异常。本文从WAL解码原理和发布配置两个层面，说明如何可靠地过滤临时表，并给出验证与排查方法。
临时表为何不会进入逻辑复制流
PostgreSQL的临时表属于会话级对象，其元数据仅对当前会话可见，数据页通过本地缓冲机制管理。与普通持久表不同，临时表上的DML操作默认不会产生WAL记录，这是因为临时表不需要崩溃恢复，也不会被其他会话访问，因此没有必要将变更写入预写日志。即使数据库的wal_level设置为logical，临时表上的插入、更新和删除依然不会记录到WAL中。
逻辑复制的数据源是发布端WAL中的行级变更，由pgoutput等解码插件负责提取。由于临时表操作根本不会出现在WAL里，解码插件自然无法捕获这些变更，所以从原理上看，临时表数据天生被排除在复制流之外。发布端不需要任何额外的过滤规则，临时表就不会被复制到订阅端。这一点让很多运维人员感到意外，因为他们发现发布列表中看起来包含了某张表，但实际复制时却没有临时数据，误以为复制链路出了问题。
真正需要警惕的是同名遮蔽现象。假设持久表public.orders已经加入发布，某用户在会话中执行了CREATE TEMP TABLE orders (LIKE public.orders)，随后在该会话中对orders执行DML。由于PostgreSQL的搜索路径默认把临时模式pg_temp放在最前面，这些DML会作用于临时表而不是持久表。持久表没有产生WAL变更，发布端也就不会向订阅端发送任何数据。结果表现为复制延迟或数据缺失，而实际上临时表数据从未进入复制流。要避免这种误解，可以在业务会话中显式指定模式名，或者调整search_path，确保DML始终落在持久表上。
通过发布配置显式控制复制范围
虽然临时表天然不会被复制，但在构建逻辑复制时，仍然建议采用显式表清单而不是贪图方便使用FOR ALL TABLES。显式清单能让发布范围一目了然，也便于后续审计和调整。创建发布时可以只指定需要复制的持久表，例如：
CREATE PUBLICATION pub_orders FOR TABLE public.orders, public.users;
如果之前已经使用FOR ALL TABLES创建了发布，后来发现某些表不需要复制，可以通过ALTER PUBLICATION ... DROP TABLE将其移除。但要注意，不能把临时表加入发布，因为临时表在创建发布的会话结束后就会消失，发布依赖的relid无法跨会话保持。尝试在另一个会话中添加临时表会直接报错，这也从侧面说明逻辑复制无法管理临时表。
行级过滤器是另一种控制复制内容的手段，它作用于持久表的WAL记录，与临时表没有直接关系，但在某些业务场景下可以用它来排除与临时处理逻辑相关的数据。例如只复制东部区域的数据：
CREATE PUBLICATION pub_orders_filtered FOR TABLE public.orders WHERE (region = 'east');
如果发布已经存在，可以使用ALTER PUBLICATION ... SET TABLE ... WHERE ...来添加或修改行过滤条件。这种过滤发生在发布端解码阶段，只有满足条件的行才会被发送到订阅端，进一步减少了网络传输和订阅端处理负担。
订阅端同名临时表的影响与排查
逻辑复制的订阅端由后台进程apply worker负责应用变更，该进程运行在独立的会话中，不会使用用户会话创建的临时表。因此，即使用户在订阅端数据库中创建了同名临时表，也不会影响复制进程本身。但问题在于普通查询或应用逻辑可能会因为同名临时表而看到不一致的数据。例如查询SELECT count(*) FROM orders时，如果当前会话存在临时表orders，查询结果来自临时表而非复制过来的持久表，这会让用户误以为复制没有正常工作。
排查这类问题，首先要确认发布端的发布列表是否只包含持久表。可以查询系统视图pg_publication_tables，该视图列出了所有发布中的表名及其所在模式。如果看到模式名为pg_temp，说明发布配置异常，但实际上临时表不会被录入该视图。正常的发布表应当都位于public或其他持久模式中。订阅端可以通过pg_stat_subscription查看复制状态，重点关注last_msg_send_time和last_msg_receipt_time是否正常，如果长时间没有更新，则需要检查发布端WAL生成和复制槽状态。
下面通过一个简单实验验证临时表不会被逻辑复制捕获。先在发布端创建持久表并建立发布：
CREATE TABLE public.rep_demo (id int primary key, note text); CREATE PUBLICATION pub_demo FOR TABLE public.rep_demo;
然后在同一个会话中创建同名临时表并插入一条数据：
CREATE TEMP TABLE rep_demo (id int, note text); INSERT INTO rep_demo VALUES (1, 'temp row');
由于临时表遮蔽了持久表，这条插入不会写入持久表的WAL，订阅端也不会收到该行。随后删除临时表并直接向public.rep_demo插入数据，订阅端才会收到这行记录。通过这种对比，可以直观理解临时表的过滤行为。如果订阅端应用进程在处理数据时调用了包含临时表操作的函数，并且该函数因为表不存在而报错，就需要调整函数逻辑，确保复制应用过程中不要依赖临时表。
总之，PostgreSQL逻辑复制对临时表的过滤是架构层面的天然行为，但实际运维中仍要关注同名遮蔽和发布范围配置，通过显式表清单、行级过滤以及系统视图监控，才能保证复制链路稳定可靠。
PostgreSQL逻辑复制临时表发布过滤修改时间：2026-08-24 18:45:57