On 2019-11-06 15:49, Tom Lane wrote:
> 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.
Committed, without the "else".
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
