openGauss 6.0.0版本崩溃

问题求助
1

2026-06-01 20:41:56.888 opengauss lt_ms_aq localhost 139622968383040 0[0:0#0] 0 [BACKEND] PANIC: CU Delete bitmap is missing.
2026-06-01 20:41:56.888 opengauss lt_ms_aq localhost 139622968383040 0[0:0#0] 0 [BACKEND] DETAIL: There might be some issue about cu 1644 delete bitmap, Please contact HW engineers for support.
2026-06-01 20:41:56.888 opengauss lt_ms_aq localhost 139622968383040 0[0:0#0] 0 [BACKEND] BACKTRACELOG: tid[3172449]'s backtrace:
/usr/local/opengauss/bin/gaussdb(+0x8cf7ab) [0x56323f5237ab]
/usr/local/opengauss/bin/gaussdb(_Z9errfinishiz+0x5bb) [0x56323f51aa0b]
/usr/local/opengauss/bin/gaussdb(_ZN6CStore21GetCUDeleteMaskIfNeedEjP12SnapshotData+0x55b) [0x5632400d9c6b]
/usr/local/opengauss/bin/gaussdb(_ZN6CStore18GetLivedRowNumbersEPl+0x108) [0x5632400dc408]
/usr/local/opengauss/bin/gaussdb(+0xc1e18c) [0x56323f87218c]
/usr/local/opengauss/bin/gaussdb(+0xc21134) [0x56323f875134]
/usr/local/opengauss/bin/gaussdb(+0xc21d18) [0x56323f875d18]
/usr/local/opengauss/bin/gaussdb(_Z11analyze_reljP10VacuumStmtP24BufferAccessStrategyData+0x2d0) [0x56323f879170]
/usr/local/opengauss/bin/gaussdb(_Z6vacuumP10VacuumStmtjbP24BufferAccessStrategyDatab+0x48d) [0x56323f9f578d]
/usr/local/opengauss/bin/gaussdb(+0xde952d) [0x56323fa3d52d]
/usr/local/opengauss/bin/gaussdb(_Z17AutoVacWorkerMainv+0x5de) [0x56323fa3f6ae]
/usr/local/opengauss/bin/gaussdb(_Z17GaussDbThreadMainIL15knl_thread_role8EEiP14knl_thread_arg+0x2c2) [0x56323fadc2c2]
/usr/local/opengauss/bin/gaussdb(+0xe56095) [0x56323faaa095]
/usr/lib64/libc.so.6(+0x8b38a) [0x7efe3bb5338a]
/usr/lib64/libc.so.6(+0x10d840) [0x7efe3bbd5840]
Use addr2line to get pretty function name and line

openGauss 6.0.0版本运行报错，请问该如何排查和处理

2

列存deletemap出现问题，是普通表还是分区表，请问能分享一下可以复现用例或者步骤吗？

ALTER SYSTEM SET autovacuum = off;
SELECT pg_reload_conf();
设置完之后，执行下面的语句，尝试定位一下哪张表出现问题。

SELECT
‘SELECT ‘’’ || n.nspname || ‘.’ || c.relname || ‘’’ AS table_name, ’ ||
‘COUNT() AS cu_rows, ’ ||
'SUM(CASE WHEN col_id = -10 THEN 1 ELSE 0 END) AS delmask_rows, ’ ||
'array_agg(col_id ORDER BY col_id) AS col_ids ’ ||
'FROM ’ || c.relcudescrelid::regclass ||
’ WHERE cu_id = 1644 HAVING COUNT() > 0;’
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE c.relcudescrelid <> 0;

3

是分区列存表，目前是有100左右个模式，每个模式有三张列分区表和四张普通表，三张列存分区表的数据量从几千万到几亿数据。每个分区表都设置有索引。

老师，下面截图是通过您说的方式查询的，是列存表的索引导致的吗？

image
image1660×864 706 KB

4

你好，问题是deletemap查不到，导致检索core。具体丢失根因如果没有可复现用例或者步骤，不太能直接看出来。请问能提供一下这个问题出现的具体背景吗？

5

这个问题6.0.5会受影响吗？新人求稳

6

发现有两张表损坏，删除重建。我升级6.05试一下

7

我觉得6.0.5也解决不了这个问题，这个是元数据损坏了，不找到损坏的原因，哪个版本应该都会有问题。

  1. 重新恢复数据

  2. 正常DDL、DML和autoVaccum应该不会导致元数据损坏。可能损坏的路径是cudesc heap 或 cudesc index 物理损坏，分区复杂的DDL / 元数据交换路径比如MERGE PARTITION等等。
    现在复现信息不足，我也没法判断。:sob: