使用pglogical从Postgres 9.6升级至14后autovacuum未运行问题咨询

现象是否为预期行为？ #

是，这种现象在使用pglogical逻辑复制升级后的PostgreSQL 14主库中属于预期行为，核心原因如下：

1. pglogical逻辑复制的特性直接处理死元组 #

pglogical基于PostgreSQL逻辑解码机制实现数据同步，当PostgreSQL 14作为pglogical的订阅端接收9.6版本的数据时，同步过程中产生的死元组会被pglogical的专用清理进程直接处理，不会留存下来积累到触发autovacuum的阈值。这就是n_dead_tup始终接近0且无变化的根本原因。

2. autovacuum触发条件未被满足 #

PostgreSQL的autovacuum启动需要满足明确阈值：

• 表内死元组数量达到 autovacuum_vacuum_threshold + autovacuum_vacuum_scale_factor × 表总行数
• 或自上次vacuum/analyze后，表的修改次数达到 autovacuum_analyze_threshold + autovacuum_analyze_scale_factor × 表总行数

由于当前PG14库中死元组无积累，且手动执行过VACUUM ANALYZE更新了统计信息，autovacuum的触发条件从未达成，因此不会产生autovacuum活动记录。

3. 流式复制不影响autovacuum逻辑 #

PG14作为主库向另一台PG14做流式物理复制，这一行为不会阻碍autovacuum运行，只是会同步autovacuum产生的WAL日志。当前场景下无autovacuum活动，完全是因为没有触发需求，和流式复制无关。

验证autovacuum功能正常性的方法 #

若要确认PG14的autovacuum功能本身无故障，可手动制造死元组进行测试：

-- 创建测试表
CREATE TABLE test_autovacuum (id INT, name TEXT);
-- 批量插入数据
INSERT INTO test_autovacuum SELECT generate_series(1,10000), 'test_data';
-- 制造死元组
UPDATE test_autovacuum SET name = 'updated' WHERE id <= 5000;
DELETE FROM test_autovacuum WHERE id > 5000;

等待10-15分钟后，执行以下命令查看状态：

SELECT relname, last_autovacuum, n_dead_tup FROM pg_stat_user_tables WHERE relname = 'test_autovacuum';

若last_autovacuum字段出现时间戳，说明autovacuum功能正常，仅当前业务场景无需触发。

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