Re: alternative to PG_CATCH - Mailing list pgsql-hackers

From Tom Lane
Subject Re: alternative to PG_CATCH
Date
Msg-id 27116.1573051770@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-04 16:01, Tom Lane wrote:
>> 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.

> I can confirm that that indeed happens. :(

> Here is a patch to fix it.

This seems all right from here.  Since PG_RE_THROW() is guaranteed
noreturn, I personally wouldn't have bothered with an "else" after it,
but that's just stylistic.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Block level parallel vacuum
Next
From: Tom Lane
Date:
Subject: Re: define bool in pgtypeslib_extern.h