PostgreSQL逻辑复制槽无新记录却持续增大，订阅故障求解析

为什么无用户事务时复制槽lag仍持续增长？ #

PostgreSQL的WAL（预写日志）不止记录用户发起的增删改操作，以下系统级操作都会生成WAL日志，哪怕目标表没有任何DML：

• 自动清理（autovacuum）：数据库中所有表的清理操作（比如回收死元组、冻结事务ID）都会写入WAL
• 统计信息更新（包括自动执行的autoanalyze）：更新统计信息的操作会产生WAL
• 其他表的DDL操作：源库中任意表的结构变更（比如建表、改表结构）都会生成WAL
• 系统表变更：比如权限调整、角色操作这类涉及系统表的修改也会写入WAL

你的订阅已经失效，订阅端不会再向源库发送「已处理完成」的LSN确认，导致confirmed_flush_lsn数值停滞。而源库会不停生成上述各类WAL，pg_current_wal_lsn()持续推进，两者的差值（也就是你看到的lag）自然会越来越大。

该lag数值与当前数据库WAL大小的关系 #

这个lag值代表订阅端没确认处理的WAL数据量，它和磁盘上现存的WAL文件大小直接相关：

• PostgreSQL的WAL清理机制会被复制槽限制，所有未被订阅端确认的WAL文件都不会被删除或归档（如果配置了归档），所以磁盘上的WAL总大小至少不会小于这个lag值
• 实际磁盘上的WAL大小可能比lag值略大，因为还包含正在写入的最新WAL段文件

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