volatile关键字在PG_TRY与PG_CATCH中的作用机制探究

核心逻辑：PG_TRY的底层实现与编译器优化 #

PostgreSQL的PG_TRY/PG_CATCH是基于C标准库的setjmp/longjmp实现的。当elog(ERROR)触发时，程序会通过longjmp直接跳转到PG_CATCH块的执行点，这一过程不会走常规的函数栈退栈流程，只会恢复setjmp保存的上下文状态。

编译器优化时，会把频繁访问的变量存到CPU寄存器里以提升效率，但longjmp只会恢复setjmp时刻的寄存器状态——PG_TRY块内对寄存器变量的修改不会同步回内存，导致PG_CATCH块读取到的是内存里的变量初始值（未初始化的int32默认是0）。

测试现象拆解 #

1. 无volatile且在try块内赋值的情况 #

代码：

Datum sample_func(PG_FUNCTION_ARGS)
{
  int32 var;
  PG_TRY();
  {
    var = 5;
    elog(ERROR, "testing");
  }
  PG_CATCH();
  {
    elog(INFO, "var : %d", var);
  }
  PG_END_TRY();

  PG_RETURN_CSTRING("Function works....");
}

输出：

INFO:  var : 0
  sample_func   
----------------
 Function Works....
(1 row)

原因：编译器将var优化到寄存器中，var=5只修改了寄存器的值，没同步到内存。longjmp跳转后，寄存器恢复为setjmp时的状态（此时var还未赋值，内存值为0），因此PG_CATCH读取到的是内存初始值。

2. 加volatile关键字的情况 #

仅修改变量声明：

volatile int32 var;

输出：

INFO:  var : 5
  sample_func   
----------------
 Function Works....
(1 row)

原因：volatile强制编译器每次读写变量都直接操作内存，禁止将变量优化到寄存器。var=5会直接写入内存，longjmp跳转后，PG_CATCH读取内存中的值就是5。

3. 在try块外赋值的情况 #

代码：

Datum sample_func(PG_FUNCTION_ARGS)
{
  int32 var;

  var = 5;
  PG_TRY();
  { 
    elog(ERROR, "testing");
  }
  PG_CATCH();
  {
    elog(INFO, "var : %d", var);
  }
  PG_END_TRY();

  PG_RETURN_CSTRING("Function works....");
}

输出：

INFO:  var : 5
  sample_func   
----------------
 Function Works....
(1 row)

原因：var=5在PG_TRY之前执行，编译器会把该赋值同步到内存（因为之后PG_TRY块内没有修改var，没必要做寄存器优化）。longjmp跳转后，内存中的var值没被改变，因此PG_CATCH能正确读取到5。

总结 #

在PG_TRY/PG_CATCH场景中，volatile的作用是阻止编译器将变量优化到寄存器，确保变量的修改会持久化到内存，让longjmp跳转后的PG_CATCH块能读取到PG_TRY块内的赋值结果。如果变量在PG_TRY块外完成赋值，编译器不会做寄存器优化，因此无需volatile也能保留值。

内容的提问来源于stack exchange，提问作者Sri