Re: alternative to PG_CATCH - Mailing list pgsql-hackers

From Tom Lane
Subject Re: alternative to PG_CATCH
Date
Msg-id 6577.1572879685@sss.pgh.pa.us
Whole thread Raw
In response to Re: alternative to PG_CATCH  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: alternative to PG_CATCH  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: cost based vacuum (parallel)
Next
From: Tom Lane
Date:
Subject: Re: v12 and pg_restore -f-