Re: [HACKERS] PG_TRY & PG_CATCH in FDW development
| От | Tom Lane |
|---|---|
| Тема | Re: [HACKERS] PG_TRY & PG_CATCH in FDW development |
| Дата | |
| Msg-id | 16531.1493131547@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | [HACKERS] PG_TRY & PG_CATCH in FDW development (Abbas Butt <abbas.butt@enterprisedb.com>) |
| Ответы |
Re: [HACKERS] PG_TRY & PG_CATCH in FDW development
|
| Список | 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 по дате отправления: