PostgreSQL 15.2初始同步自动创建的逻辑复制槽问题咨询

场景说明：PostgreSQL 15.2中，初始同步期间自动创建的单表逻辑复制槽出现wal_status = lost且active = false的异常状态，槽详情如下：

slot_name   plugin  slot_type   datoid  database    temporary   active  active_pid  xmin    catalog_xmin    restart_lsn confirmed_flush_lsn wal_status  safe_wal_size   two_phase
pg_8034820_sync_8033089_7371741997992267844 pgoutput    logical 16707   aaa_db  FALSE   FALSE   NULL    NULL    295098502   NULL    D9/EB7317B0 lost    NULL    FALSE
pg_6839631_sync_6837833_7371741997992267844 pgoutput    logical 16707   aaa_db  FALSE   FALSE   NULL    NULL    288349892   NULL    D2/80068A78 lost    NULL    FALSE

1. 谁负责清理这些异常的复制槽？ #

PostgreSQL不会自动清理这类异常的逻辑复制槽，需要由数据库管理员手动处理。可执行以下SQL删除指定槽：

SELECT pg_drop_replication_slot('pg_8034820_sync_8033089_7371741997992267844');

也可编写自定义监控脚本，识别active = false且wal_status = lost的异常槽，实现自动清理。

2. 处于"wal_status = lost"状态的复制槽能否恢复？ #

不能恢复。wal_status = lost表示该复制槽所需的WAL日志已被清理（可能是超过wal_keep_segments配置的保留数量，或是归档后从本地pg_wal目录删除），无法再获取必要的WAL数据，该槽已失去作用，只能删除。

3. 这种情况下我需要删除订阅吗？ #

不需要，除非订阅本身已故障无法正常同步。这些异常槽是初始同步阶段遗留的临时产物，只要订阅对应的主复制槽（若存在）状态正常，订阅可继续运行。建议先手动删除异常槽，再通过以下SQL检查订阅状态：

-- 查看订阅基本信息
SELECT * FROM pg_subscription;
-- 查看订阅与表的关联同步状态
SELECT * FROM pg_subscription_rel;

若上述查询显示订阅同步正常，无需删除订阅。

4. 这些单表同步的复制槽会占用max_connections的连接和max_logical_replication_slots的槽位吗？ #

• 不会占用max_connections的连接配额：因为这些槽的active = false，没有对应的活跃数据库连接。
• 会占用max_logical_replication_slots的槽位配额：只要复制槽存在，无论是否活跃，都会占用配置的逻辑复制槽总数额度。

5. 同步大量表时，是增加max_logical_replication_slots数量更好，还是让部分表等待其他表完成后释放槽位再使用？ #

需结合硬件资源、WAL存储能力和同步需求权衡：

• 优先增加槽位的场景：如果服务器CPU、IO资源充足，且已配置合理的WAL保留策略（如足够大的wal_keep_segments或pg_replication_slots.max_wal_size），可以增加max_logical_replication_slots数量，并行同步大量表，大幅提升初始同步速度。PostgreSQL 15+支持通过PARALLEL_SYNC参数（创建订阅时设置PARALLEL_SYNC = n）控制并行同步的表数量，避免无限制创建槽。
• 优先排队等待的场景：如果服务器资源有限，或WAL存储/保留能力不足，建议让表排队同步。过多并行槽会消耗大量WAL资源，容易出现wal_status = lost的异常，甚至影响主库性能。

内容的提问来源于stack exchange，提问作者user1409708