复制槽能够阻止 PostgreSQL 回收消费者尚未确认的 WAL。这是流复制和逻辑复制可靠性的基础，也是一项容易拖垮磁盘的承诺：只要复制槽还存在，即使消费者早已下线，服务端仍可能继续保留 WAL。PostgreSQL 18 新增 idle_replication_slot_timeout，让管理员可以为长期闲置的复制槽设置失效期限。
复制槽为什么会变成磁盘风险
物理复制槽通常服务于备用节点，逻辑复制槽则可能连接订阅端、CDC 平台或自研数据管道。消费者正常工作时，它会不断推进槽记录的 LSN，PostgreSQL 随后便能回收更早的 WAL。
问题出在消费者永久消失、环境被销毁或者迁移流程遗漏清理时。复制槽本身不会因为客户端断开就自动消失，于是 pg_wal 可能持续增长。磁盘告警只是表象，更严重的结果是数据库所在文件系统被占满，最终影响事务写入和检查点。
以往常见的治理方式包括：
- 定期查询
pg_replication_slots，由值班人员判断并删除废弃槽； - 设置
max_slot_wal_keep_size，限制复制槽最多保留多少 WAL； - 在创建和销毁订阅端时同步管理复制槽生命周期。
这些措施仍然有价值，但它们分别依赖人工判断、限制保留体积或外部编排。idle_replication_slot_timeout 增加的是时间维度：一个复制槽闲置太久后，可以被 PostgreSQL 判定为不可继续使用。
超时意味着失效，不意味着消费者自动恢复
这个参数适合处理“消费者已经被遗弃”的场景，而不是普通的短时故障。超时发生后，旧消费者不能再假定自己可以从原槽记录的位置无损续传；逻辑复制或 CDC 系统通常需要重新初始化快照、重建复制槽，并核对期间的数据缺口。
复制槽的超时检查与检查点有关，因此达到配置时长并不代表系统会在那一毫秒立即处理。运维告警和演练脚本不应把它当作精确计时器。
它也不完全替代 max_slot_wal_keep_size：
idle_replication_slot_timeout控制闲置时间，适合清理无人使用的槽；max_slot_wal_keep_size控制 WAL 保留规模，为磁盘容量提供另一道边界；- 活跃但推进缓慢的消费者未必会被“闲置超时”覆盖，仍需监控 LSN 延迟和 WAL 占用。
可以这样实践：配置、检查与回滚
下面示例假设服务器已经升级到 PostgreSQL 18，并且当前账号具有修改系统参数的权限。请把 24h 改成大于业务最长维护窗口、最长容灾中断时间和可接受重建时间的值。
psql -X -v ON_ERROR_STOP=1 postgres <<'SQL'
ALTER SYSTEM SET idle_replication_slot_timeout = '24h';
SELECT pg_reload_conf();
SHOW idle_replication_slot_timeout;
SQL
上线前应先观察现有复制槽。以下查询列出槽类型、活动状态、闲置起点和保留 WAL 的粗略体积；不同复制拓扑下，LSN 字段的解释可能不同，因此结果应结合消费者状态判断。
psql -X -P pager=off postgres <<'SQL'
SELECT
slot_name,
slot_type,
database,
active,
inactive_since,
pg_size_pretty(
pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)
) AS retained_wal,
wal_status
FROM pg_replication_slots
ORDER BY active, inactive_since NULLS LAST;
SQL
若需要取消超时策略，可以恢复默认配置并重新加载：
psql -X -v ON_ERROR_STOP=1 postgres <<'SQL'
ALTER SYSTEM RESET idle_replication_slot_timeout;
SELECT pg_reload_conf();
SHOW idle_replication_slot_timeout;
SQL
不要在自动化脚本中仅凭 active = false 就删除复制槽。备库维护、订阅端发布和网络隔离都可能让一个健康消费者暂时断开。至少还要核对槽名称的所有者、inactive_since、WAL 保留量以及对应服务的部署状态。
上线时需要定下的规则
启用这一参数之前，团队需要明确三个问题：最长允许消费者离线多久、槽失效后由谁执行重新初始化、如何识别计划内停机。建议先用查询和告警积累一段时间的数据，再把超时值设为正常离线窗口的数倍，并在预生产环境演练槽失效后的恢复流程。
更稳妥的组合是同时建立容量和时间边界：用磁盘与 WAL 保留量告警发现快速增长，用 max_slot_wal_keep_size 限制极端占用，再用 idle_replication_slot_timeout 处理被遗忘的复制槽。这样既保留复制槽带来的可靠性，也避免“永久保留”演变成没有上限的磁盘债务。