max_replication_slots是静态参数，修改后必须重启实例才生效；未重启时建槽会报“all replication slots are in use”错误，可通过对比pg_settings中setting与boot_val确认是否生效。
max_replication_slots 设定后为什么复制槽不生效
postgresql 的 max_replication_slots 是个静态参数，改完必须重启实例才能加载。很多用户在线执行 ALTER SYSTEM SET max_replication_slots = 5 后立刻建槽，结果报错 Error: all replication slots are in use——其实根本没生效。
- 确认是否重启：查
pg_settings中max_replication_slots的setting值和boot_val是否一致，不一致说明配置未载入 - 动态参数如
max_connections可 reload，但这个不是；postgresql.conf修改后必须pg_ctl restart或系统级systemctl restart postgresql - 注意：slot 名称区分大小写，且不能含空格或特殊字符，否则
CREATE_REPLICATION_SLOT直接报语法错误
逻辑复制槽泄漏的典型现象和定位方法
泄漏本质是 slot 持有 WAL 不被回收，导致 pg_wal/ 目录持续膨胀，甚至撑爆磁盘。最直接信号是 pg_replication_slots 视图里 active 为 f，但 restart_lsn 长期不动。
- 检查滞留槽：
select slot_name, plugin, active, restart_lsn, confirmed_flush_lsn FROM pg_replication_slots WHERE NOT active; - 对比
restart_lsn和当前pg_control_checkpoint().redo（可用pg_controldata命令看），差值超 1GB WAL 就该警惕 - 常见泄漏场景：消费者进程崩溃未清理 slot、kafka Connect / Debezium 任务停用但没调
DROP_REPLICATION_SLOT、应用层重试逻辑误建同名 slot
pg_replication_slots.active = false 但 WAL 还在增长
PostgreSQL 不会自动清理 inactive slot 的 WAL，只要它存在，WAL 就得保留到 restart_lsn。哪怕 slot 已停用一周，只要没删，归档和流复制都会卡住。
- 安全清理前先确认：该 slot 对应的下游是否真不再需要（比如旧同步任务已下线）
- 删除命令必须在对应数据库连接中执行：
SELECT pg_drop_replication_slot('slot_name');，不能跨库操作 - 若删槽时报
ERROR: replication slot "xxx" is active for PID xxx，说明还有 backend 在用——查pg_stat_replication或pg_stat_activity找出 PID 并 kill - 注意：slot 删除后，WAL 清理不会立即发生，需等待下一个 checkpoint 完成
监控脚本里容易漏掉的关键字段
只盯 active 列会误判。真正反映风险的是 restart_lsn 和 pg_current_wal_lsn() 的差值，以及 catalog_xmin 是否长期停滞（影响系统表垃圾回收）。
- 推荐监控 SQL：
SELECT slot_name, active, restart_lsn, pg_current_wal_lsn() - restart_lsn AS lsn_lag_bytes FROM pg_replication_slots; -
lsn_lag_bytes超过 2GB 建议告警；超过 10GB 必须人工介入 - 不要依赖
pg_stat_replication，它只显示活跃连接，inactive slot 完全不出现 - 备份脚本如果包含
pg_create_logical_replication_slot，务必配对pg_drop_replication_slot，否则每次备份都新增一个泄漏点
事情说清了就结束。最麻烦的不是设上限，而是没人定期核对 pg_replication_slots 里那些 active = f 的条目——它们安静躺在那里，默默吃光你的磁盘空间。