测试类型

工具功能
存储功能
故障注入

测试版本

6.0.6LTS

操作系统和硬件信息

openEuler release 24.03 (LTS) aarch64

测试环境

企业版主备

操作步骤

-- 环境一：cmp 6.0.6（15700），打开 enable_cbm_tracking 后构造最小链路
DROP DATABASE IF EXISTS db_for_probackup_1061897;
CREATE DATABASE db_for_probackup_1061897;
\c db_for_probackup_1061897
CREATE TABLESPACE tbs_1061897_1 LOCATION '/home/wcl0716/ts_1061897_1';
CREATE TABLESPACE tbs_1061897_2 LOCATION '/home/wcl0716/ts_1061897_2';
CREATE TABLESPACE tbs_1061897_3 LOCATION '/home/wcl0716/ts_1061897_3';
CREATE TABLE ustore_alter_1061897(
    id int,
    col_new_smallint smallint,
    payload text,
    updated_at timestamp default clock_timestamp()
) WITH (orientation=row, storage_type=ustore) TABLESPACE tbs_1061897_1;
CREATE INDEX idx_ustore_alter_1061897_id ON ustore_alter_1061897(id) TABLESPACE tbs_1061897_2;
INSERT INTO ustore_alter_1061897
SELECT g, (g % 30000)::smallint, repeat('x', 200)
FROM generate_series(1, 50000) g;

-- FULL -> PTRACK -> PTRACK
-- gs_probackup init/add-instance/backup FULL
-- 业务变更 1：UPDATE/INSERT/DELETE/CHECKPOINT
-- gs_probackup backup -b PTRACK
-- 业务变更 2：UPDATE/INSERT/DELETE/CHECKPOINT
-- gs_probackup backup -b PTRACK

-- 恢复最新增备
-- gs_probackup restore -B /home/wcl0716/probackup_1061897 --instance=i1061897 -D /home/wcl0716/cluster/dn1 -i TIVJQ6 -I checksum

-- 恢复后执行
\c db_for_probackup_1061897
SELECT count(*) AS rows_before_alter FROM ustore_alter_1061897;
ALTER TABLE ustore_alter_1061897 ALTER COLUMN col_new_smallint TYPE int;
SELECT count(*) AS rows_after_alter FROM ustore_alter_1061897;

-- 若 standby 进入 Need repair(WAL)，在 standby 节点执行
-- gs_ctl build -D /home/wcl0716/cluster/dn1 -b full

-- 环境二：lts 7.0.0-RC3（15600）按相同链路对照执行
-- 同样构造 5 万行 USTORE 表 + FULL/PTRACK/PTRACK + restore -I checksum
-- 再执行 ALTER TABLE ... ALTER COLUMN col_new_smallint TYPE int;

预期输出

1. FULL/PTRACK/PTRACK 备份成功
2. restore -I checksum 成功
3. 恢复后 ALTER TABLE ... ALTER COLUMN col_new_smallint TYPE int 正常完成
4. standby build/start 正常完成，主备集群保持 Normal，无 core / 无 coredump

实际输出

【cmp 6.0.6】
1. FULL/PTRACK/PTRACK 均成功，restore -I checksum 成功。
2. 第一次恢复后：
   - rows_before_alter = 53778
   - ALTER TABLE ustore_alter_1061897 ALTER COLUMN col_new_smallint TYPE int; 长时间不返回
   - pg_stat_activity 显示该会话 state=active, waiting=f，持有 AccessExclusiveLock
   - core=0
3. 第二次按同一备份链重放恢复后：
   - 再次手动执行相同 ALTER，现象一致：rows_before_alter 正常返回，ALTER 长时间不返回
   - 同样 state=active, waiting=f，core=0
4. 两次 restore 之后，cmp standby 都进入 Need repair(WAL)。
5. 对 20.20.20.226 执行 gs_ctl build -D /home/wcl0716/cluster/dn1 -b full 时，17:18:13 再次报：
   gaussDB state is Coredump
6. 修正 core_pattern 后，成功落盘：
   /home/wcl0716/core/core-gaussdb-3913846-2026_07_28_17_18_07-bbox.lz4
7. 解压后确认为 ELF core file，gdb 栈显示线程落在：
   - BBOX_CreateCoredump
   - parallel_recovery::GetCompletedReadEndPtr
   - parallel_recovery::GetReplayedRecPtrFromUndoWorkers
   - parallel_recovery::PageRedoWorkerMain
   - StartupXLOG / StartupProcessMain

【lts 7.0.0-RC3 对照】
1. 同样的 FULL/PTRACK/PTRACK + restore -I checksum 成功。
2. rows_before_alter = 53778
3. ALTER TABLE ... ALTER COLUMN col_new_smallint TYPE int; 直接成功
4. rows_after_alter = 53778
5. core=0，集群 Normal

日志信息

cmp 6.0.6 上至少两次稳定复现“增量恢复后 USTORE smallint->int 改列卡住”；lts 7.0.0-RC3 同链路不复现。进一步在 cmp 上补抓到真实 core：standby full build/start 时进入 Coredump，核心文件为 /home/wcl0716/core/core-gaussdb-3913846-2026_07_28_17_18_07-bbox.lz4。gdb 栈已收敛到 standby StartupXLOG / parallel_recovery / UNDO replay 相关路径；同时 pg_log 持续出现 RecheckUndoRecycleXid / globalFrozenXid 告警，当前判断更像旧版本增量恢复后 USTORE 物理/元数据状态异常。

提单组织

测试团队