Re: alternative to PG_CATCH

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 2019-11-02 15:36, Tom Lane wrote:
>> I hadn't actually tested this patch before commit, but now that
>> it's in, I'm seeing assorted compiler warnings:

> I've fixed the ones that I could reproduce on CentOS 6.  I haven't seen 
> any on a variety of newer systems.

I'd hoped for a way to fix PG_FINALLY rather than having to band-aid
the individual callers :-(.  But maybe there isn't one.

Now that I've actually looked at the patched code, there's a far
more severe problem with it.  Namely, that use of PG_FINALLY
means that the "finally" segment is run without having popped
the error context stack, which means that any error thrown
within that segment will sigsetjmp right back to the top,
resulting in an infinite loop.  (Well, not infinite, because
it'll crash out once the error nesting depth limit is hit.)
We *must* pop the stack before running recovery code.

Possibly this could be fixed like so:

#define PG_FINALLY() \
        } \
        else \
        { \
            PG_exception_stack = _save_exception_stack; \
            error_context_stack = _save_context_stack; \
            _do_rethrow = true

#define PG_END_TRY()  \
        } \
        if (_do_rethrow) \
                PG_RE_THROW(); \
        PG_exception_stack = _save_exception_stack; \
        error_context_stack = _save_context_stack; \
    } while (0)

But I haven't tested that.

            regards, tom lane