Re: alternative to PG_CATCH - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: alternative to PG_CATCH
Date
Msg-id b4a3bae5-4fe5-a1c2-7349-9b017957d490@2ndquadrant.com
Whole thread Raw
In response to Re: alternative to PG_CATCH  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: alternative to PG_CATCH  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: deferrable FK constraints on partitioned rels
Next
From: Pavel Stehule
Date:
Subject: Re: Why overhead of SPI is so large?