Welcome To openGauss Community
Hey @wuchenlong , thanks for your contribution to the community.
Bot Usage Manual
I'm the Bot here serving you. You can find the instructions on how to interact with me at Here . That means you can comment below every pull request or issue to trigger Bot Commands.
Contact Guide
If you have any questions, please contact the SIG: StorageEngine, AI, CM, CloudNative, SecurityTechnology, SQLEngine ,
and any of the maintainers: @CarrotGo, @chendong76, @chenxiaobin19, @congzhou2603, @dodders, @hwworkholic, @jemappellehc, @muyulinzhong, @quemingjian, @shenzheng4, @shirley_zhengx, @superlchf, @totaj, @wlff234, @ywzq1161327784 ,
and any of the committers: @Igali, @bihua111, @cailei19, @h_ray, @levy53071, @libiao2024, @lihaixiao, @mrzack, @wangfeihuo, @wuyuechuan, @xiong_xjun, @zhangfengzhi123, @zhangxubo, @zjh_hw .


1.经过分析,autovacuum现在流程上有问题,初步判断是https://gitcode.com/opengauss/openGauss-server/pull/8865/diffs这个pr带入,,这个代码会导致跳过autovacuum实际处理流程(可以用astore表表跑这个用例,也是一样的结果),已经联系提交人确认。
2.ustore方面,因为ustore更新时,老数据都是放入undo空间而不是数据页,所以相对astore,dead tuple会更少,不依赖vacuum清理,实际上ustore表页面dead tuple清理发生在dml执行过程中。autovacuum任务对于ustore只会执行analyze不执行vacuum。
。所以就这个用例来说,dead tuple不因为autovacuum而清0是正常现象。


测试类型
存储功能
测试版本
7.0.0LTS
问题描述
【长江存储】ustore 表在 UPDATE/DELETE 产生死亡元组后,autovacuum 仅触发 analyze(或未触发 vacuum),pg_stat_user_tables 中 n_dead_tup 长期不清零,last_autovacuum 始终为空。
操作系统和硬件信息
openEuler release 24.03 (LTS) aarch64
测试环境
企业版主备
被测功能
ustore autovacuum / vacuum
预置条件
autovacuum=on;主库执行(pg_is_in_recovery()=f)
操作步骤
ROLLBACK;
DROP TABLE IF EXISTS t_ustore_autovac_test;
CREATE TABLE t_ustore_autovac_test (
id bigint primary key,
info text
) WITH (STORAGE_TYPE = 'USTORE');
INSERT INTO t_ustore_autovac_test
SELECT generate_series(1,10000), 'test_data_'||generate_series(1,10000);
ANALYZE t_ustore_autovac_test;
SELECT relname, n_live_tup, n_dead_tup, last_autoanalyze, last_autovacuum
FROM pg_stat_user_tables
WHERE relname = 't_ustore_autovac_test';
UPDATE t_ustore_autovac_test SET info = 'update_data' WHERE id <= 5000;
DELETE FROM t_ustore_autovac_test WHERE id > 8000;
SELECT relname, n_live_tup, n_dead_tup, last_autoanalyze, last_autovacuum
FROM pg_stat_user_tables
WHERE relname = 't_ustore_autovac_test';
ALTER SYSTEM SET autovacuum_naptime to 30;
SELECT pg_reload_conf();
-- 等待 autovacuum 至少 3 个周期(约 3 分钟)后执行:
SELECT relname, n_live_tup, n_dead_tup, last_autoanalyze, last_autovacuum,
autovacuum_count, autoanalyze_count
FROM pg_stat_user_tables
WHERE relname = 't_ustore_autovac_test';
预期输出
autovacuum 应对 ustore 表执行 vacuum,n_dead_tup 清零或显著下降,last_autovacuum 有时间戳。
实际输出
等待 180s(autovacuum_naptime=30s)后查询:
实际行数 SELECT count(*) FROM t_ustore_autovac_test 为 8000。n_dead_tup 未清零,last_autovacuum 为空,autovacuum_count=0。
日志信息
pg_log 可见 autovacuum launcher 周期性 start autovacuum on database "postgres",但未对 t_ustore_autovac_test 记录 automatic vacuum;手动 VACUUM 日志显示 vacuuming uheap 但 found 0 removable row versions。
提单组织
一线客户