openGauss 中 PGTRY/PGCATCH 机制详解 openGauss使用 C 语言编写，而 C 语言没有内置的异常处理机制。为了实现 try/catch 语义，openGauss 使用了一组基于 sigsetjmp/siglongjmp（POSIX 非局部跳转机制）构建的宏。本文将从 C 宏层面一直到 aarch64 汇编层面，完整剖析这一实现。第一部分：PGTRY、PGCATCH、PGENDTRY 1.1 宏定义错误处理宏定义在 src/include/utils/elog.h（第 442-466 行）：#define PG_TRY() \ do { \ sigjmp_buf* save_exception_stack = t_thrd.log_cxt.PG_exception_stack; \ ErrorContextCallback* save_context_stack = t_thrd.log_cxt.error_context_stack; \ sigjmp_buf local_sigjmp_buf; \ int tryCounter, *oldTryCounter = NULL; \ if (sigsetjmp(local_sigjmp_buf, 0) == 0) { \ t_thrd.log_cxt.PG_exception_stack = &local_sigjmp_buf; \ oldTryCounter = gstrace_tryblock_entry(&tryCounter) #define PG_CATCH() \ } \ else \ { \ t_thrd.log_cxt.PG_exception_stack = save_exception_stack; \ t_thrd.log_cxt.error_context_stack = save_context_stack; \ gstrace_tryblock_exit(true, oldTryCounter) #define PG_END_TRY() \ } \ t_thrd.log_cxt.PG_exception_stack = save_exception_stack; \ t_thrd.log_cxt.error_context_stack = save_context_stack; \ gstrace_tryblock_exit(false, oldTryCounter); \ } \ while (0) 1.2 宏展开后的形式当你编写如下代码时：PG_TRY(); { // ... 可能出错的代码 ... } PG_CATCH(); { // ... 错误处理 ... } PG_END_TRY(); 宏展开后变为：do { sigjmp_buf* save_exception_stack = t_thrd.log_cxt.PG_exception_stack; ErrorContextCallback* save_context_stack = t_thrd.log_cxt.error_context_stack; sigjmp_buf local_sigjmp_buf; int tryCounter, *oldTryCounter = NULL; if (sigsetjmp(local_sigjmp_buf, 0) == 0) { // 首次调用：sigsetjmp 返回 0 t_thrd.log_cxt.PG_exception_stack = &local_sigjmp_buf; oldTryCounter = gstrace_tryblock_entry(&tryCounter); // === TRY 代码体 === } else { // 错误路径：siglongjmp 使 sigsetjmp "返回"非零值 t_thrd.log_cxt.PG_exception_stack = save_exception_stack; t_thrd.log_cxt.error_context_stack = save_context_stack; gstrace_tryblock_exit(true, oldTryCounter); // === CATCH 代码体 === } t_thrd.log_cxt.PG_exception_stack = save_exception_stack; t_thrd.log_cxt.error_context_stack = save_context_stack; gstrace_tryblock_exit(false, oldTryCounter); } while (0); 核心机制： 1.sigsetjmp(local_sigjmp_buf, 0)将当前 CPU 状态（寄存器、栈指针、程序计数器）保存到local_sigjmp_buf中，并返回0。TRY 代码体开始执行。 2.如果发生错误，siglongjmp(local_sigjmp_buf, 1)恢复之前保存的 CPU 状态，使sigsetjmp"返回"1。由于1 == 0为假，else分支（CATCH 代码体）开始执行。 3.gstrace_tryblock_entry/gstrace_tryblock_exit是 openGauss 追溯系统的插桩钩子，在正常构建中会被编译为空操作（no-op）。 1.3 异常栈 PG_exception_stack 是一个线程局部指针（t_thrd.log_cxt.PG_exception_stack），始终指向最内层活跃的 PG_TRY 的 local_sigjmp_buf。它充当跳转目标的链表： ●PG_TRY：将当前PG_exception_stack保存到save_exception_stack，然后将自己的&local_sigjmp_buf安装为新的栈顶。 ●PG_CATCH：将PG_exception_stack恢复为save_exception_stack（弹出自身）。 ●PGENDTRY：同样恢复PG_exception_stack（处理无错误的正常路径）。当错误触发时，siglongjmp(*PG_exception_stack, 1) 总是跳转到最外层的处理器。 1.4 嵌套的 PGTRY/PGCATCH 考虑以下嵌套结构：/* PG_exception_stack = NULL（或某个外层处理器） */ PG_TRY(); /* 外层 */ { PG_TRY(); /* 内层 */ { ereport(ERROR, (errmsg("boom"))); } PG_CATCH(); { PG_RE_THROW(); } PG_END_TRY(); } PG_CATCH(); { /* 处理错误 */ } PG_END_TRY(); 以下是 PG_exception_stack 在执行过程中的变化：步骤 1：进入任何 PG_TRY 之前 PG_exception_stack ──→ （外层处理器或 NULL）步骤 2：进入外层 PG_TRY save_exception_stack_A = PG_exception_stack sigsetjmp(buf_A, 0) → 返回 0 PG_exception_stack ──→ buf_A ──→ （外层处理器）步骤 3：进入内层 PG_TRY save_exception_stack_B = PG_exception_stack (= &buf_A) sigsetjmp(buf_B, 0) → 返回 0 PG_exception_stack ──→ buf_B ──→ buf_A ──→ （外层处理器）步骤 4：ereport(ERROR) 触发 siglongjmp(*PG_exception_stack, 1) = siglongjmp(buf_B, 1) → 跳转到内层 PG_CATCH 步骤 5：内层 PG_CATCH 执行 PG_exception_stack = save_exception_stack_B PG_exception_stack ──→ buf_A ──→ （外层处理器）步骤 6：内层 PG_CATCH 中的 PG_RE_THROW() siglongjmp(*PG_exception_stack, 1) = siglongjmp(buf_A, 1) → 跳转到外层 PG_CATCH 步骤 7：外层 PG_CATCH 执行 PG_exception_stack = save_exception_stack_A PG_exception_stack ──→ （外层处理器或 NULL）栈的可视化表示： ┌─────────┐ 步骤 3： │ buf_B │ ← PG_exception_stack（最内层） ├─────────┤ │ buf_A │ ├─────────┤ │ 外层 │ └─────────┘ 内层 PG_CATCH ┌─────────┐ 之后： │ buf_A │ ← PG_exception_stack ├─────────┤ │ 外层 │ └─────────┘ 外层 PG_CATCH ┌─────────┐ 之后： │ 外层 │ ← PG_exception_stack └─────────┘ 每个 PG_TRY 压栈，每个 PG_CATCH 或 PG_END_TRY 弹栈。错误总是跳转到栈顶。第二部分：sigsetjmp 与 siglongjmp sigsetjmp 和 siglongjmp 是 PGTRY/PGCATCH 背后的引擎。sigsetjmp 保存一个 CPU 检查点；siglongjmp 恢复它。要理解它们的底层逻辑，我们需要查看 glibc 中的 aarch64 汇编实现。 2.1 aarch64 寄存器在 aarch64（ARM 64 位）架构上，CPU 有 31 个通用寄存器和一个栈指针。以下是与 sigsetjmp/siglongjmp 相关的寄存器：寄存器名称作用 x0 — 第一个函数参数；同时也是返回值 x1 — 第二个函数参数 x0-x18 — 调用者保存（临时寄存器）— 函数可以自由覆盖 x19-x28 — 被调用者保存 — 如果函数使用了这些寄存器，必须在返回前恢复 x29 FP（帧指针）指向当前函数的栈帧 x30 LR（链接寄存器）保存返回地址 — 函数返回时跳转的目标 sp 栈指针指向当前栈顶 d8-d15 — 被调用者保存的浮点/SIMD 寄存器当你用 bl func（带链接的分支）调用函数时，CPU 自动将下一条指令的地址写入 x30（LR）。当函数执行 ret 时，它跳转到 x30 中的地址。这就是 ARM 上函数调用和返回的工作方式。 2.2 关键汇编指令指令含义示例 stp Store Pair — 将两个寄存器写入内存 stp x19, x20, [x0, #0] → 将 x19 和 x20 存储到地址 x0+0 ldp Load Pair — 从内存读取两个值到寄存器 ldp x19, x20, [x0, #0] → 从地址 x0+0 加载到 x19、x20 str Store Register — 将一个寄存器写入内存 str x2, [x0, #96] → 将 x2 存储到地址 x0+96 ldr Load Register — 从内存读取一个值到寄存器 ldr x2, [x0, #96] → 从地址 x0+96 加载到 x2 mov Move — 在寄存器间复制值或加载立即数 mov x0, #0 → 将 x0 设为 0 bl Branch and Link — 调用函数（将返回地址保存到 x30） bl sigsetjmp → 调用 sigsetjmp br Branch — 跳转到寄存器中的地址 br x30 → 跳转到 x30 中的地址 ret Return — 等价于 br x30 返回调用者 cmp Compare — 比较两个值，设置条件标志 cmp x0, #0 → x0 是否等于 0？ cbz Compare and Branch if Zero — 为零则跳转 cbz x1, label → 如果 x1 == 0，跳转到 label csinc Conditional Select and Increment — 条件选择并加一 csinc x0, x0, xzr, ne → 若不等则保持 x0，否则 x0 = 0+1 xzr 是零寄存器 — 读取时始终为 0。 2.3 jmp_buf 结构在查看汇编之前，先了解 sigsetjmp 保存数据的目标结构。类型链如下：// openGauss 中： #define sigjmp_buf jmp_buf // glibc 中（setjmp/setjmp.h）： typedef struct __jmp_buf_tag jmp_buf[1]; // 长度为 1 的数组 — 使其自动退化为指针的技巧 // 结构体（setjmp/bits/types/struct___jmp_buf_tag.h）： struct __jmp_buf_tag { __jmp_buf __jmpbuf; // 寄存器存储区 int __mask_was_saved; // 是否保存了信号掩码？ __sigset_t __saved_mask; // 保存的信号掩码（128 字节） }; // 寄存器数组（sysdeps/aarch64/bits/setjmp.h）： typedef unsigned long long __jmp_buf[22]; // 22 个槽位 × 8 字节 = 176 字节 typedef ... jmp_buf[1] 中的 [1] 是一个 C 语言技巧：它使 jmp_buf 成为数组类型，传递给函数时自动退化为指针。这样你可以写 sigsetjmp(buf, 0) 而不是 sigsetjmp(&buf, 0)。 22 个槽位的寄存器数组布局（来自 sysdeps/aarch64/jmpbuf-offsets.h）：索引偏移（字节）内容 ───── ───────────── ─────────────────── [0] 0 x19 [1] 8 x20 [2] 16 x21 [3] 24 x22 [4] 32 x23 [5] 40 x24 [6] 48 x25 [7] 56 x26 [8] 64 x27 [9] 72 x28 [10] 80 x29 (FP) [11] 88 x30 (LR) — 返回地址（传送目的地） [12] 96 （保留） [13] 104 sp（栈指针） [14] 112 d8 [15] 120 d9 [16] 128 d10 [17] 136 d11 [18] 144 d12 [19] 152 d13 [20] 160 d14 [21] 168 d15 完整的 jmp_buf 内存布局：┌─────────────────────────────────────────────────┐ │ __jmpbuf[22] （176 字节） │ │ [0-9] x19-x28 （被调用者保存的通用寄存器）│ │ [10] x29 (FP) │ │ [11] x30 (LR) ← 传送目的地 │ │ [12] （保留） │ │ [13] sp ← 栈检查点 │ │ [14-21] d8-d15 （被调用者保存的浮点寄存器）│ ├─────────────────────────────────────────────────┤ │ __mask_was_saved （int，0 或 1） │ ├─────────────────────────────────────────────────┤ │ __saved_mask （sigset_t，128 字节） │ │ 被阻塞信号的位掩码 │ │ （仅在 __mask_was_saved == 1 时填充） │ └─────────────────────────────────────────────────┘ 2.4 sigsetjmp — 保存检查点 glibc 源码位于 sysdeps/aarch64/setjmp.S。以下是 __sigsetjmp 的核心部分，逐行注释：ENTRY_ALIGN (__sigsetjmp, 2) 1: ;; x0 = 指向 jmp_buf 的指针（第一个参数） ;; x1 = savesigs 标志（第二个参数；PG_TRY 中为 0） ;; 将被调用者保存的通用寄存器存入 jmp_buf stp x19, x20, [x0, #JB_X19<<3] ;; 将 x19,x20 存储到 buf + 0 stp x21, x22, [x0, #JB_X21<<3] ;; 将 x21,x22 存储到 buf + 16 stp x23, x24, [x0, #JB_X23<<3] ;; 将 x23,x24 存储到 buf + 32 stp x25, x26, [x0, #JB_X25<<3] ;; 将 x25,x26 存储到 buf + 48 stp x27, x28, [x0, #JB_X27<<3] ;; 将 x27,x28 存储到 buf + 64 ;; 保存帧指针和链接寄存器（返回地址） ;; PTR_MANGLE 会用密钥对 x30 进行异或加密以增强安全性 stp x29, x30, [x0, #JB_X29<<3] ;; 将 FP,LR 存储到 buf + 80 ;; 保存被调用者保存的浮点寄存器 stp d8, d9, [x0, #JB_D8<<3] ;; 将 d8,d9 存储到 buf + 112 stp d10, d11, [x0, #JB_D10<<3] ;; 将 d10,d11 存储到 buf + 128 stp d12, d13, [x0, #JB_D12<<3] ;; 将 d12,d13 存储到 buf + 144 stp d14, d15, [x0, #JB_D14<<3] ;; 将 d14,d15 存储到 buf + 160 ;; 保存栈指针（不能直接从 sp 执行 stp） mov x2, sp str x2, [x0, #JB_SP<<3] ;; 将 sp 存储到 buf + 104 ;; 跳转到 __sigjmp_save（一个 C 函数），该函数： ;; - 设置 buf->__mask_was_saved = savesigs (= 0) ;; - 如果 savesigs != 0，调用 sigprocmask 保存信号掩码 ;; - 返回 0 b __sigjmp_save 关键的保存是 x30（LR）— 此时 x30 保存的是调用者中 bl __sigsetjmp 之后那条指令的地址。这就是 siglongjmp 将要跳回的"传送目的地"。 __sigjmp_save 返回 0，这成为 sigsetjmp 的返回值。调用者看到 0，进入 TRY 代码体。 2.5 siglongjmp — 恢复检查点 siglongjmp 执行相反的操作 — 从缓冲区加载所有保存的寄存器，然后跳转到保存的返回地址： ;; x0 = 指向 jmp_buf 的指针（第一个参数） ;; x1 = 要伪造的返回值（第二个参数；PG_RE_THROW 中为 1） ;; 恢复被调用者保存的通用寄存器 ldp x19, x20, [x0, #JB_X19<<3] ;; 从 buf + 0 加载 x19,x20 ldp x21, x22, [x0, #JB_X21<<3] ;; 从 buf + 16 加载 x21,x22 ldp x23, x24, [x0, #JB_X23<<3] ;; 从 buf + 32 加载 x23,x24 ldp x25, x26, [x0, #JB_X25<<3] ;; 从 buf + 48 加载 x25,x26 ldp x27, x28, [x0, #JB_X27<<3] ;; 从 buf + 64 加载 x27,x28 ;; 恢复帧指针和链接寄存器 ldp x29, x30, [x0, #JB_X29<<3] ;; 从 buf + 80 加载 FP,LR ;; 恢复浮点寄存器 ldp d8, d9, [x0, #JB_D8<<3] ldp d10, d11, [x0, #JB_D10<<3] ldp d12, d13, [x0, #JB_D12<<3] ldp d14, d15, [x0, #JB_D14<<3] ;; 恢复栈指针 ldr x2, [x0, #JB_SP<<3] ;; 从 buf + 104 加载保存的 sp mov sp, x2 ;; 恢复栈指针 ;; 设置返回值：x0 = x1（val 参数） ;; 但如果 val == 0，强制设为 1（sigsetjmp 通过 longjmp 返回时不能为 0） mov x0, x1 ;; x0 = val (= 1) cmp x0, #0 csinc x0, x0, xzr, ne ;; 若不等于零则保持 x0；否则 x0 = 1 ;; 跳转到保存的返回地址 br x30 ;; 传送回 sigsetjmp 调用点 br x30 执行后，CPU 现在正在执行原始 sigsetjmp 调用之后的那条指令。栈指针已恢复，所有被调用者保存的寄存器已恢复，x0（返回值寄存器）为 1。调用者编译后的代码执行 cmp w0, #0 — 发现 1 != 0 — 进入 CATCH 分支。 2.6 完整生命周期调用者： bl __sigsetjmp ;; bl 将 (PC+4) 写入 x30，跳转到 sigsetjmp ;; ← x30 指向这里 sigsetjmp： stp ... [buf] ;; 保存 x19-x30（包括返回地址）、sp、d8-d15 → __sigjmp_save → 返回 0 ;; x0 = 0 ;; 调用者看到 0 → 进入 TRY 代码体 ... 时间流逝，代码执行，错误发生 ... siglongjmp： ldp ... [buf] ;; 从同一个 buf 恢复 x19-x30、sp、d8-d15 mov x0, 1 ;; x0 = 1（返回值） br x30 ;; 跳转到保存的返回地址 ;; 调用者看到 1 → 进入 CATCH 代码体 2.7 siglongjmp 链式跳转到 PostgresMain 当错误在嵌套的 PG_TRY 块中向外冒泡时，siglongjmp 会多次触发，每次向外跳转一层：┌─────────────────────────────────────────────────────────────────────┐ │ PostgresMain │ │ sigsetjmp(buf_A, 1) ← PG_exception_stack = &buf_A │ │ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ some_function: PG_TRY │ │ │ │ sigsetjmp(buf_B, 0) ← PG_exception_stack = &buf_B │ │ │ │ │ │ │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ │ │ another_function: PG_TRY │ │ │ │ │ │ sigsetjmp(buf_C, 0) ← PG_exception_stack = &buf_C │ │ │ │ │ │ │ │ │ │ │ ereport(ERROR) │ │ │ │ │ │ → errfinish() │ │ │ │ │ │ → PG_RE_THROW() │ │ │ │ │ │ → siglongjmp(buf_C, 1) ─────┐ │ │ │ │ │ │ │ │ │ │ │ │ │ PG_CATCH: ◄────────────────────────┘ │ │ │ │ │ │ PG_exception_stack = &buf_B │ │ │ │ │ │ PG_RE_THROW() │ │ │ │ │ │ → siglongjmp(buf_B, 1) ─────┐ │ │ │ │ │ └─────────────────────────────────────│───────────────┘ │ │ │ │ │ │ │ │ │ PG_CATCH: ◄───────────────────────────┘ │ │ │ │ PG_exception_stack = &buf_A │ │ │ │ PG_RE_THROW() │ │ │ │ → siglongjmp(buf_A, 1) ─────┐ │ │ │ └─────────────────────────────────────│───────────────────────┘ │ │ │ │ │ 错误恢复：◄───────────────────────────┘ │ │ EmitErrorReport() │ │ AbortCurrentTransaction() │ │ → 回到查询循环 │ └─────────────────────────────────────────────────────────────────────┘ 每次 siglongjmp 都会将 CPU 传送回 — 寄存器、栈指针、程序计数器 — 对应的 sigsetjmp 检查点。中间的栈帧被直接抛弃（不会逐帧展开）。没有析构函数运行，没有自动清理。这就是为什么每个 PG_CATCH 必须自行完成清理工作。第三部分：pgrethrow 与 errfinish 当 ereport(ERROR) 被调用时，它通过 errfinish() 和 pg_re_throw() 将错误传递到最近的 PG_CATCH。这两个函数形成的调用链看起来像递归，但实际上不是 — 因为 siglongjmp 在递归发生之前就中断了调用链。 3.1 errfinish — ERROR 分支 errfinish() 定义在 src/common/backend/utils/error/elog.cpp（第 555 行）。完整函数处理所有错误级别，但对于 ERROR 只有以下分支起作用（第 656-691 行）：void errfinish(int dummy, ...) { ErrorData* edata = &t_thrd.log_cxt.errordata[t_thrd.log_cxt.errordata_stack_depth]; int elevel = edata->elevel; // ... 初始化、上下文回调、回溯信息 ... if (elevel == ERROR || is_warnings_throw) { /* * 在 longjmp 之前进行最小化清理，使处理器能在 * 合理正常的状态下执行。 */ /* 禁用立即中断处理 */ t_thrd.int_cxt.ImmediateInterruptOK = false; /* 重置中断挂起计数器 — 如果错误发生在 * HOLD_INTERRUPTS() 区段内，计数器会卡住， * 跳转后中断将永远被阻塞。 */ t_thrd.int_cxt.InterruptHoldoffCount = 0; t_thrd.int_cxt.QueryCancelHoldoffCount = 0; t_thrd.int_cxt.InterruptCountResetFlag = true; /* 重置临界区计数 — 同理 */ t_thrd.int_cxt.CritSectionCount = 0; t_thrd.log_cxt.recursion_depth--; PG_RE_THROW(); } // ... 以下代码仅在非 ERROR 级别时执行 ... // 对于 < ERROR：EmitErrorReport()，释放 ErrorData，正常返回 // 对于 FATAL：EmitErrorReport()，释放 ErrorData，proc_exit(1) // 对于 PANIC：EmitErrorReport()，释放 ErrorData，abort() } 关键观察： 1.对于ERROR，errfinish不会调用EmitErrorReport()。错误消息留在errordata栈上，未被发送。发送与否由 PG_CATCH 处理器决定。 2.唯一做的工作是重置中断/临界区状态，确保跳转目标不会处于异常状态。 3.第 690 行的PG_RE_THROW()是出口 — 它调用siglongjmp，永不返回。第 691 行之后的所有代码对于 ERROR 都不可达。 3.2 pgrethrow — 执行跳转 PG_RE_THROW() 是一个宏（elog.h 第 511 行），展开为 pg_re_throw()：// elog.h 第 511 行 #define PG_RE_THROW() pg_re_throw() 函数实现（elog.cpp 第 2441-2487 行）：void pg_re_throw(void) { /* 如果可能，将错误抛给下一个外层 setjmp 处理器 */ if (t_thrd.log_cxt.PG_exception_stack != NULL) siglongjmp(*t_thrd.log_cxt.PG_exception_stack, 1); else { /* * 没有外层处理器。如果错误一开始就在 PG_TRY 块外抛出， * 我们会将其提升为 FATAL。所以现在也这样做。 */ ErrorData* edata = &t_thrd.log_cxt.errordata[t_thrd.log_cxt.errordata_stack_depth]; edata->elevel = FATAL; t_thrd.log_cxt.error_context_stack = NULL; errfinish(0); } /* 不应到达此处 */ ExceptionalCondition("pg_re_throw tried to return", "FailedAssertion", __FILE__, __LINE__); abort(); } 两条路径： ●正常情况（PG_exception_stack != NULL）：siglongjmp跳转到最近的 PG_CATCH。永不返回。 ●无外层处理器（PG_exception_stack == NULL）：将错误从 ERROR 提升为 FATAL，然后调用errfinish(0)。这次errfinish看到elevel == FATAL，跳过 ERROR 分支，发送错误消息，然后调用proc_exit(1)— 后端进程终止。 3.3 表面上的递归调用链看起来像递归：ereport(ERROR) → errfinish() // elevel == ERROR → PG_RE_THROW() → pg_re_throw() → siglongjmp() ← 永不返回 — 跳转到 PG_CATCH errfinish 调用 pg_re_throw，后者看似会回调 errfinish（通过 FATAL 回退路径）。但在正常情况下，siglongjmp 触发后调用链被抛弃 — pg_re_throw 永远不会返回到 errfinish，errfinish 也永远不会继续执行 PG_RE_THROW() 之后的代码。在 PG_exception_stack == NULL 的边界情况下：errfinish() // elevel == ERROR → PG_RE_THROW() → pg_re_throw() → PG_exception_stack == NULL → edata->elevel = FATAL → errfinish(0) // 这次 elevel == FATAL → elevel == FATAL，跳过 ERROR 分支 → EmitErrorReport() → proc_exit(1) ← 进程终止，不再递归第二次调用 errfinish 看到的是 FATAL，走完全不同的代码路径，终止进程。因此即使在这种边界情况下，"递归"也只有一层深度并会终止。 3.4 完整的 ERROR 流程ereport(ERROR, (errmsg("boom"))) │ ├─ errstart() // 将 ErrorData 压入错误栈 ├─ errmsg("boom") // 填充错误消息 └─ errfinish() │ ├─ elevel == ERROR ├─ 重置 InterruptHoldoffCount、CritSectionCount └─ PG_RE_THROW() │ └─ pg_re_throw() │ ├─ PG_exception_stack != NULL？ │ 是 → siglongjmp(*PG_exception_stack, 1) │ ──→ CPU 传送到最近的 PG_CATCH │ ──→ ErrorData 仍在栈上，未发送 │ ──→ PG_CATCH 处理器决定如何处理 │ └─ PG_exception_stack == NULL？是 → 提升为 FATAL → errfinish(0) → EmitErrorReport() → proc_exit(1) 第四部分：PostgresMain — 最外层错误处理器所有 PGTRY/PGCATCH 块最终都会将错误冒泡到 PostgresMain，即每个后端进程的主循环。但 PostgresMain 并不使用 PG_TRY/PG_CATCH — 它使用原始的 sigsetjmp。 4.1 为什么不用 PG_TRY？ src/gausskernel/process/tcop/postgres.cpp（第 9070-9075 行）中的注释解释了原因：/* * PG_TRY construct. The reason is that this is the bottom of the * exception stack, and so with PG_TRY there would be no exception handler * active at all during the CATCH part. By leaving the outermost setjmp * always active, we have at least some chance of recovering from an error * during error recovery. (If we get into an infinite loop thereby, it * will soon be stopped by overflow of elog.c's internal state stack.) */ 在最外层使用 PG_TRY 的问题在于：PG_CATCH 会将 PG_exception_stack 恢复为之前的值。在最外层，之前的值是 NULL。因此在整个 CATCH 代码体执行期间，PG_exception_stack 都是 NULL。如果在错误恢复过程中触发了任何错误（例如 EmitErrorReport() 失败），pg_re_throw() 会发现 PG_exception_stack == NULL，将错误提升为 FATAL，直接杀死进程。使用原始 sigsetjmp 时，PostgresMain 始终保持 PG_exception_stack 指向自己的 local_sigjmp_buf — 即使在错误恢复期间也是如此。如果发生"恢复中的错误"，siglongjmp 会跳回同一个 sigsetjmp 检查点，错误恢复块从头开始重新执行。这给了后端第二次恢复的机会，而不是直接死亡。 4.2 代码/* 第 9079 行 */ if (sigsetjmp(local_sigjmp_buf, 1) != 0) { /* ===== 错误恢复块 ===== */ /* 重置状态标志 */ t_thrd.log_cxt.error_context_stack = NULL; t_thrd.log_cxt.call_stack = NULL; // ... 重置各种会话/线程标志 ... /* 在清理期间阻止中断 */ HOLD_INTERRUPTS(); /* 取消待处理的查询，禁用定时器 */ t_thrd.int_cxt.QueryCancelPending = false; disable_sig_alarm(true); /* 重置通信层 */ fn_comm_reset(); /* ---- 错误在此处到达客户端和日志 ---- */ EmitErrorReport(); /* 第 9170 行 */ // ... 大量会话状态清理 ... /* 中止事务 — GUC 值在此恢复， * 锁被释放，WAL 回滚，内存上下文重置 */ AbortCurrentTransaction(); /* 第 9262 行 */ /* 释放剩余资源 */ LWLockReleaseAll(); AbortBufferIO(); /* 重新启用中断 */ RESUME_INTERRUPTS(); } /* ===== 正常路径（首次 sigsetjmp 返回，或恢复之后） ===== */ /* 将自身安装为错误处理器 */ t_thrd.log_cxt.PG_exception_stack = &local_sigjmp_buf; /* 第 9391 行 */ /* 进入主查询处理循环 */ for (;;) { ReadCommand(...); exec_simple_query(...); // ... } 注意 sigsetjmp(local_sigjmp_buf, 1) 的 savesigs 参数使用了 1（而 PG_TRY 使用 0）。这意味着信号掩码也会被保存和恢复 — 在最外层这很重要，错误发生后信号处理状态必须完全重置。 4.3 sigsetjmp 的两次返回首次调用： sigsetjmp(local_sigjmp_buf, 1) → 返回 0 0 != 0 → 假 → 跳过错误恢复 → 设置 PG_exception_stack = &local_sigjmp_buf → 进入查询循环之后，当错误冒泡上来时： siglongjmp(local_sigjmp_buf, 1) → sigsetjmp "返回" 1 1 != 0 → 真 → 进入错误恢复块 → EmitErrorReport、AbortCurrentTransaction、清理 → 落入正常路径 → PG_exception_stack = &local_sigjmp_buf（重新装填） → 再次进入查询循环，准备处理下一个查询 4.4 完整的错误生命周期将所有部分串联起来 — 从调用栈深处的 ereport(ERROR) 到客户端收到错误消息：┌─ PostgresMain ──────────────────────────────────────────────────────┐ │ │ │ sigsetjmp(buf, 1) → 0（首次） │ │ PG_exception_stack = &buf │ │ ┌─ 查询循环 ────────────────────────────────────────────────────┐ │ │ │ exec_simple_query │ │ │ │ → ProcessUtility │ │ │ │ → CreateExtension │ │ │ │ → execute_extension_script │ │ │ │ ┌─ PG_TRY（内层）─────────────────────────────────┐ │ │ │ │ │ ereport(ERROR, "boom") │ │ │ │ │ │ → errfinish() │ │ │ │ │ │ → PG_RE_THROW() │ │ │ │ │ │ → siglongjmp(inner_buf, 1) ──┐ │ │ │ │ │ │ │ │ │ │ │ │ │ PG_CATCH: ◄────────────────────────┘ │ │ │ │ │ │ 局部清理（AtEOXact_GUC for nestlevel） │ │ │ │ │ │ PG_RE_THROW() │ │ │ │ │ │ → siglongjmp(buf, 1) ──────────────┐ │ │ │ │ │ └─────────────────────────────────────────│────────┘ │ │ │ └────────────────────────────────────────────────────│───────────┘ │ │ │ │ │ sigsetjmp(buf, 1) → 1（错误！）◄─────────────────────┘ │ │ │ │ ┌─ 错误恢复 ────────────────────────────────────────────────────┐ │ │ │ 1. 重置状态标志，挂起中断 │ │ │ │ 2. EmitErrorReport() ← 错误发送到客户端和日志 │ │ │ │ 3. AbortCurrentTransaction() ← 回滚、GUC 恢复、 │ │ │ │ 锁释放、内存重置 │ │ │ │ 4. 恢复中断 │ │ │ └───────────────────────────────────────────────────────────────┘ │ │ │ │ PG_exception_stack = &buf（为下一个错误重新装填） │ │ → 回到查询循环，准备处理下一个客户端命令 │ └──────────────────────────────────────────────────────────────────────┘ 后端在错误中存活下来，继续为客户端提供服务。事务被回滚，所有状态被清理，下一个查询从全新状态开始。这就是让 openGauss 后端在查询失败后依然保持存活的根本错误恢复循环。