Description of problem:
postgresql is failing its regression tests in rawhide since about two days ago.  Debugging the problem reveals that an error-handling chunk of code reached by setjmp() is failing to restore a global variable that it is supposed to restore.

Normally I would think that this is a gcc issue, especially since it goes away at -O0.  But gcc hasn't changed recently and the appearance of the problem coincides with the introduction of glibc-2.14.90-15.1 into rawhide.  So I'm wondering if longjmp is now forgetting to restore some registers, or something like that.

Version-Release number of selected component (if applicable):
glibc-2.14.90-15.1

How reproducible:
100%

Steps to Reproduce:
1.  Try to build current postgresql SRPM (9.1.1-2)
  
Actual results:
Regression test failure for plpython module --- it prints one line that it shouldn't.

Expected results:
No failure.

Additional info:
Failure is observed on both x86_64 and i386 architectures.

The problematic code looks approximately like this:


static PLyProcedure *PLy_curr_procedure = NULL;

Datum
plpython_call_handler(FunctionCallInfo fcinfo)
{
 PLyProcedure *save_curr_proc;

 save_curr_proc = PLy_curr_procedure;

 do {
    sigjmp_buf *save_exception_stack = PG_exception_stack;
    sigjmp_buf local_sigjmp_buf;

    if (__sigsetjmp (local_sigjmp_buf, 0) == 0) {
      PG_exception_stack = &local_sigjmp_buf;
      ...
    } else {
      PG_exception_stack = save_exception_stack;
      PLy_curr_procedure = save_curr_proc;  // this assignment is getting lost
      PyErr_Clear();
      pg_re_throw(); // this does a longjmp(), so it doesn't return
    }
    PG_exception_stack = save_exception_stack;
 } while (0);

 PLy_curr_procedure = save_curr_proc;
 ...
}


and the observed behavior is that PLy_curr_procedure isn't getting restored during a longjmp exit.