This issue requires an assignee. Since you haven't specified one, we've assigned TestManager as the default assignee for this issue.

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. You can self-configure the PR merge rules for this repository. For more details, please refer to Here.

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, @libiao2024, @muyulinzhong, @quemingjian, @shenzheng4, @shirley_zhengx, @superlchf, @totaj, @wlff234, @wofanzheng, @ywzq1161327784 ,
and any of the committers: @Igali, @bihua111, @cailei19, @h_ray, @levy53071, @libiao2024, @lihaixiao, @mrzack, @wangfeihuo, @wuyuechuan, @xiong_xjun, @zhangfengzhi123, @zhangxubo, @zhangzq131, @zjh_hw .

验证版本：700B21
验证结果：通过

回归版本：openGauss 7.0.0 build bc72a519（B022）；修复前对照 build 93bfec54
回归环境：224/226/228 三节点主备（ARM），profile=cmp（wcl0716:15700），cluster_state=Normal
结论：通过（备库不再 SIGSEGV，集群保持 Normal）

说明：按 issue 最小复现流程在修复前与修复后各执行一次。

• 修复前 93bfec54：备库 226 持 pg_class(1259) AccessShareLock 长事务 + 主库 224 生成 AccessExclusive standby-lock WAL → 备库 SIGSEGV，进程消失，落 core，集群 Degraded。
• 修复后 B022 (bc72a519)：同样步骤备库不再崩溃，进程存活、15700 正常、无新 core，集群保持 Normal。

修复前 93bfec54（对照复现）

-- 步骤1 备机 226 持 AccessShareLock
BEGIN;
SET statement_timeout = 0;
SELECT count(*) FROM pg_catalog.pg_class;
SELECT pg_sleep(3600);

-- 步骤1 持锁确认
select pid,mode,granted from pg_locks where relation=1259;
→ 281466992709504|AccessShareLock|t

-- 步骤2 主机 224 生成 AccessExclusive WAL
SET xc_maintenance_mode = on;
BEGIN;
LOCK TABLE pg_catalog.pg_class IN ACCESS EXCLUSIVE MODE;
COMMIT;
→ SET / COMMIT 成功

-- 步骤3 备机 226
- 备机 gaussdb 进程消失，15700 无监听
- gsql: failed to connect Unknown:15700
- core: /home/wcl0716/core/core-startup-2166229-1788948709 (6.8G)
- gs_om: 226 S Down Manually stopped；集群 Degraded

-- gdb 崩溃栈（与 issue 完全一致）
Program terminated with signal SIGSEGV, Segmentation fault.
#0  StandbyAcquireAccessExclusiveLock(unsigned long, unsigned int, unsigned int, unsigned int)
#1  standby_redo(XLogReaderState*)
#2  ApplyRedoRecord(XLogReaderState*)
#3  parallel_recovery::ApplyReadyTxnLogRecords(...)
#4  parallel_recovery::ProcessPendingRecords(bool)
#5  parallel_recovery::DispatchRedoRecordToFile(...)
#6  StartupXLOG()
#7  StartupProcessMain()

修复后 B022 / bc72a519（回归）

-- 步骤1 备机 226 持 AccessShareLock
BEGIN;
SET statement_timeout = 0;
SELECT count(*) FROM pg_catalog.pg_class;
SELECT pg_sleep(3600);

-- 步骤1 持锁确认
select pid,mode,granted from pg_locks where relation=1259;
→ 281467005292416|AccessShareLock|t

-- 步骤2 主机 224 生成 AccessExclusive WAL
SET xc_maintenance_mode = on;
BEGIN;
LOCK TABLE pg_catalog.pg_class IN ACCESS EXCLUSIVE MODE;
COMMIT;
→ SET / COMMIT 成功

-- 步骤3 备机 226（修复后）
- 备机 gaussdb 进程存活（-M standby，监听 15700）
- 无新 core（core-startup-* 仅修复前残留，本次未新增）
- 期间短暂 failed to connect（备库处理锁冲突/取消冲突查询），随后自动恢复
- gs_om: 224 P Primary Normal / 226 S Standby Normal / 228 S Standby Normal，cluster_state=Normal

说明：

1. 本次把 226 core_pattern 临时改为 wcl0716 可写的 /home/wcl0716/core（原为 wcl0716 无权限的 /home/wcl0623/core），故修复前崩溃成功落得 core-startup-2166229-1788948709，与 issue 原始 core 命名一致。
2. 与长稳 env2（139/141/143，ustore TPCC 主写 + 双备只读）持续运行 1x24h 备库不再 core dump、主备复制不再中断的结论一致。