On 2019-11-06 15:49, Tom Lane wrote:
Peter Eisentraut <peter.eisentr...@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
