From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Abbas Butt <abbas(dot)butt(at)enterprisedb(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PG_TRY & PG_CATCH in FDW development |
Date: | 2017-04-25 14:45:47 |
Message-ID: | 16531.1493131547@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Abbas Butt <abbas(dot)butt(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | K S, Sandhya (Nokia - IN/Bangalore) | 2017-04-25 14:54:08 | Re: Crash observed during the start of the Postgres process |
Previous Message | Robert Haas | 2017-04-25 14:45:34 | Re: TAP tests - installcheck vs check |