Thread: [HACKERS] PG_TRY & PG_CATCH in FDW development
I want to share a technical problem that I am facing while writing code for an FDW.
The problem is as follows:
In the FDW call back functions it is recommended to use PG_TRY PG_CATCH blocks along with PG_RE_THROW to disconnect from the foreign server.
I am using the same technique in IterateForeignScan function, and it is supposed to work like this:
1 PG_TRY();
2 {
3 ... code that might throw ereport(ERROR) ...
4 }
5 PG_CATCH();
6 {
7 disconnect_from_foreign_server();
8 PG_RE_THROW();
9 }
10 PG_END_TRY();
PG_RE_THROW is supposed to throw the same error again and then take us out of the function.
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.My question is what could possibly cause this infinite loop?
--
Abbas
Follow us on Twitter
@EnterpriseDB
Visit EnterpriseDB for tutorials, webinars, whitepapers and more
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
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
--
Abbas
Follow us on Twitter
@EnterpriseDB
Visit EnterpriseDB for tutorials, webinars, whitepapers and more