PostgreSQL 的逻辑复制依赖复制槽记录订阅端的消费进度。如果订阅端长时间宕机或复制连接中断，发布端的 WAL 文件会不断累积，最终可能撑满磁盘。遇到这种情况，除了尽快恢复订阅端之外，还可以使用 PostgreSQL 提供的复制槽推进函数，让槽位跳过一部分已经不再需要的事务。本文围绕逻辑复制槽的手动推进操作展开，说明函数的使用条件、执行效果以及需要承担的风险。
一、逻辑复制槽为什么会卡住 WAL
逻辑复制槽在 PostgreSQL 中扮演着记录消费进度的角色。发布端通过逻辑解码将事务变更发送给订阅端，订阅端消费后反馈 LSN（日志序列号），发布端据此更新槽位的 confirmed_flush_lsn。只要槽位存在且未推进，从 restart_lsn 开始的所有 WAL 文件都会被保留，以保证订阅端重新连接后能够从断点继续获取变更。
问题出现在订阅端长期不可用、复制连接频繁中断或者订阅端已经被废弃但槽位没有删除的时候。此时槽位的 confirmed_flush_lsn 停留在旧位置，而发布端还在不断产生新的 WAL。PostgreSQL 的 WAL 清理机制会跳过这些被复制槽引用的文件，最终导致磁盘使用率持续上升。对于物理复制槽，推进的是 restart_lsn；对于逻辑复制槽，推进的是 confirmed_flush_lsn，但两者都可以使用同一个函数来完成手动推进。
需要特别注意，逻辑复制槽与物理复制槽的推进语义略有不同。物理槽推进后，备库如果落后于 restart_lsn 就需要重新搭建；逻辑槽推进后，订阅端会跳过从旧 confirmed_flush_lsn 到新 confirmed_flush_lsn 之间的所有事务，这些事务不会再被发送到任何订阅端。因此手动推进逻辑复制槽本质上是一种主动放弃部分复制数据的操作，必须在确认这些数据不再需要之后才能执行。
二、pg_replication_slot_advance 函数如何使用
PostgreSQL 提供了函数 pg_replication_slot_advance 来手动推进复制槽。虽然有些资料会提到 logical_replication_slot_advance，但官方函数名并不带 logical 前缀，同一个函数同时适用于物理槽和逻辑槽。该函数的签名如下：
pg_replication_slot_advance(slot_name name, upto_lsn pg_lsn)
第一个参数是复制槽的名称，第二个参数是目标 LSN，表示希望将槽位推进到哪个位置。函数执行后会返回一行记录，包含槽位名称和实际推进后的 LSN。执行该函数需要超级用户权限，普通用户即使拥有复制权限也无法调用。在实际操作前，可以先通过 pg_replication_slots 视图查看当前槽位的状态：
SELECT slot_name, slot_type, active, restart_lsn, confirmed_flush_lsn FROM pg_replication_slots WHERE slot_name = 'my_logical_slot';
假设查询结果显示该逻辑槽的 confirmed_flush_lsn 为 0/16B6C50，而当前 WAL 位置远大于这个值。如果确认订阅端已经不再需要之前的事务，可以直接将槽位推进到当前 WAL 位置：
SELECT * FROM pg_replication_slot_advance('my_logical_slot', pg_current_wal_lsn());
执行完成后，槽位的 confirmed_flush_lsn 会被更新为当前 WAL 的插入位置。此时 Postmaster 的 checkpointer 进程会在下一次检查点执行时清理不再被引用的 WAL 文件。对于逻辑复制槽，推进 confirmed_flush_lsn 也会间接影响 restart_lsn 的回收，因为那些早于 confirmed_flush_lsn 的事务对应的 WAL 已经不再需要保留给订阅端。
三、手动推进前必须确认的状态
手动推进逻辑复制槽并不是一个可以随意执行的操作。在推进之前，需要检查槽位的 active 状态。如果槽位处于 active 状态，说明当前有一个活跃的复制连接正在使用该槽。此时强行推进会让正在运行的订阅端出现错误，或者导致订阅端错过部分事务。通常只有槽位处于 inactive 状态，也就是没有任何订阅端连接时，才考虑手动推进。
另一个需要确认的信息是订阅端是否真的不再需要这些数据。如果订阅端只是暂时离线，但后续还需要补齐数据，手动推进到当前 LSN 会导致这些数据永远丢失。更好的做法是等待订阅端恢复，让复制连接自动推进槽位。手动推进只能作为紧急处理磁盘空间不足的一种手段，或者用于清理已经废弃的订阅关系。
可以通过查询 pg_stat_replication 视图来确认订阅端最后一次反馈的位置。如果该订阅端的 write_lsn 或 flush_lsn 与当前 WAL 位置差距很大，说明它已经严重落后，需要评估是否有必要继续保留这个订阅关系。如果确定不再需要该订阅端，直接删除复制槽 pg_drop_replication_slot 比手动推进更加彻底和安全。
四、实战：跳过卡住的逻辑复制事务
假设有一个名为 logical_slot_1 的逻辑复制槽，对应的订阅端因为硬件故障已经离线数小时。发布端数据库的 WAL 目录占用接近磁盘上限，同时监控显示大量 WAL 文件被保留。先通过以下 SQL 确认该槽位的落后程度：
SELECT slot_name, active,
pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) AS lag_bytes,
confirmed_flush_lsn
FROM pg_replication_slots
WHERE slot_name = 'logical_slot_1';
查询结果显示 lag_bytes 数值很大，active 为 false。此时如果业务上已经确认该订阅端不再使用，或者即使恢复订阅端也不需要历史数据，可以执行手动推进。最直接的方式是将槽位推进到当前 WAL 位置：
SELECT slot_name, end_lsn
FROM pg_replication_slot_advance('logical_slot_1', pg_current_wal_lsn());
执行完成后再次查询 pg_replication_slots，可以看到 confirmed_flush_lsn 已经更新。接下来 PostgreSQL 会在后续检查点中清理掉不再被引用的 WAL 文件。如果需要更精细地控制跳过的范围，也可以先将槽位推进到某个历史 LSN，再观察磁盘释放情况，而不是一次性推进到最新位置。
还有一种做法是先通过 pg_wal_lsn_diff 计算需要释放的空间，然后选择一个合适的中间 LSN 进行推进，避免一次性跳过太多事务。不过对于大多数紧急场景，直接推进到当前 WAL 位置是恢复磁盘空间最快的方法。
五、风险与替代方案
手动推进逻辑复制槽最大的风险是数据丢失。一旦 confirmed_flush_lsn 越过某些事务，这些事务对应的逻辑变更就不会再发送给任何订阅端。如果订阅端后续需要重建，只能从新的槽位开始全量同步，无法增量补齐被跳过的事务。因此执行前务必确认所有订阅端要么已经消费到该位置，要么不再需要这些数据。
替代方案之一是修复订阅端并让其重新连接。如果订阅端只是网络抖动导致短暂离线，PostgreSQL 的复制连接会自动恢复，槽位也会自动推进。另一种方案是保留槽位但增加磁盘空间，同时监控 WAL 堆积速度。对于已经废弃的订阅关系，直接删除槽位 pg_drop_replication_slot 比手动推进更合适，因为删除槽位可以立即释放所有被引用的 WAL 文件。
为了防止类似问题再次发生，建议监控 pg_replication_slots 中 restart_lsn 与当前 WAL 位置的差值，设置告警阈值。同时定期检查没有再被使用的订阅关系，及时清理废弃槽位。手动推进逻辑复制槽应该作为应急手段保留，而不是常规运维操作。
PostgreSQL逻辑复制槽pg_replication_slot_advance修改时间：2026-09-25 23:17:46