应定期扫描pg_replication_slots，筛选active=false且wal偏移超1gb的逻辑复制槽，结合业务下线证据确认废弃后，用replication权限用户执行安全drop命令清理，避免仅依赖槽数量告警。
max_replication_slots 超限后 pg_replication_slots 不清空怎么办
PostgreSQL 的逻辑复制槽（logical replication slot）一旦创建，即使客户端断连、消费者崩溃或未消费，槽位仍会持续保留 WAL，导致 pg_replication_slots 里残留大量 active = false 但 restart_lsn 卡住的槽。这不是 bug，是设计行为——槽只靠显式 pg_drop_replication_slot() 清理。
常见错误现象：ERROR: all replication slots are in use；pg_stat_replication 为空但 pg_replication_slots 有十几个 inactive 槽；WAL 文件持续堆积，磁盘告警。
- 必须定期扫描
pg_replication_slots，过滤出active = false且confirmed_flush_lsn IS NOT NULL（说明曾正常工作过）但长期未推进的槽 - 判断“长期”不能只看时间戳（
catalog_xmin或create_time不可靠），应结合restart_lsn和当前pg_current_wal_lsn()差值：差值 > 1GB WAL 通常意味着卡死 - 避免误删正在被其他服务（如 Debezium、wal2json 客户端）重建中的槽——加一层
slot_name ~ '^myapp_.*'白名单匹配，别用LIKE '%_old'这类模糊规则
用 SQL 查出待清理的逻辑槽并生成 DROP 语句
直接查表只能看到状态，真正要操作得拼出安全可执行的 DROP 命令。关键不是“找出所有 inactive”，而是“找出可确认废弃的 inactive”。
使用场景：运维巡检脚本、Prometheus exporter 数据采集前预处理、Ansible 批量清理任务。
- 先算 WAL 偏移量：
(pg_current_wal_lsn() - restart_lsn) > 1073741824（1GB），单位是字节，注意 PostgreSQL 10+ 支持 LSN 减法 - 排除系统槽：
slot_type = 'logical'且plugin IN ('pgoutput', 'wal2json', 'decoderbufs')，避免误碰物理复制槽或内置插件 - 输出格式必须带引号和条件检查：
SELECT format('SELECT pg_drop_replication_slot(''%I'') WHERE EXISTS (SELECT 1 FROM pg_replication_slots WHERE slot_name = ''%I'' AND active = false);', slot_name, slot_name) FROM pg_replication_slots WHERE slot_type = 'logical' AND active = false AND (pg_current_wal_lsn() - restart_lsn) > 1073741824;
在 cron 里跑监控脚本时的权限与事务陷阱
用普通用户执行 pg_drop_replication_slot() 会报 ERROR: must be superuser or replication role to drop replication slot，但给应用账号 superuser 权限又太危险。
性能影响小，但兼容性风险集中：PostgreSQL 12 之前不支持在事务块里调用 pg_drop_replication_slot()，而很多脚本默认套了 BEGIN; ...; COMMIT;。
- 运行脚本的数据库用户必须有
REPLICATION属性（ALTER USER mymonitor WITH REPLICATION;），无需 superuser - 绝对不要在事务中执行
DROP—— 每条pg_drop_replication_slot()必须独占一个隐式事务 - 加超时控制：psql 调用时加
-v ON_ERROR_STOP=1 --set=statement_timeout=30s，防止某个卡死槽阻塞整个清理流程 - 日志里记录
slot_name和restart_lsn，别只记 “dropped 3 slots” —— 后续审计要能回溯到具体哪个槽、为什么删
为什么不能只依赖 max_replication_slots 值做告警阈值
max_replication_slots 是硬上限，但槽位泄漏的实质问题是 WAL 积压，不是数字接近上限。等报错才处理，往往已丢数据或触发主库 OOM。
容易踩的坑：监控项只采集 count(*) FROM pg_replication_slots，设阈值为 max_replication_slots * 0.8。这完全忽略槽的活性——可能 10 个槽里 9 个是僵尸，1 个是活的，但 WAL 早把磁盘打爆了。
- 核心指标应该是
pg_current_wal_lsn() - restart_lsn的最大值（单位字节），不是槽数量 - 配合
pg_replication_slots.catalog_xmin看是否拖慢 vacuum（若catalog_xmin异常小，说明该槽阻碍了系统表清理） - PostgreSQL 15+ 可用
pg_replication_slots.advanced_cleanup（需开启），但默认关闭，别假设它自动帮你兜底
最麻烦的点不在怎么删，而在怎么确认“这个槽真的没人用了”。业务方口头说“不用了”，不如看 confirmed_flush_lsn 三个月没动、下游 Kafka topic 没新消息、对应服务进程已下线这三个证据链。缺一不可。
