Re: [HACKERS] PG_TRY & PG_CATCH in FDW development - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] PG_TRY & PG_CATCH in FDW development
Date
Msg-id 16531.1493131547@sss.pgh.pa.us
Whole thread Raw
In response to [HACKERS] PG_TRY & PG_CATCH in FDW development  (Abbas Butt <abbas.butt@enterprisedb.com>)
Responses Re: [HACKERS] PG_TRY & PG_CATCH in FDW development  (Abbas Butt <abbas.butt@enterprisedb.com>)
List pgsql-hackers
Abbas Butt <abbas.butt@enterprisedb.com> writes:
> What is happening for me is that PG_RE_THROW takes me to PG_TRY in the same
> function and then PG_TRY jumps to PG_CATCH where PG_RE_THROW again jumps to
> PG_TRY in the same function resulting in an infinite loop. The query
> therefore never returns. It is supposed to throw the error and quit.

Apparently PG_exception_stack isn't getting restored properly, but it's
sure hard to see why.  I'm suspicious that you have something silly like
mismatched braces in the vicinity of the TRY/CATCH structure.

FWIW, doing things like disconnecting remote sessions might be better
handled in transaction-cleanup logic, anyway.  What covers you for that
if the query aborts while control is not within your PG_TRY block?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] TAP tests - installcheck vs check
Next
From: "K S, Sandhya (Nokia - IN/Bangalore)"
Date:
Subject: Re: [HACKERS] [BUGS] Crash observed during the start of the Postgres process