Dear Fujii-san,
Thank you for good suggestions.
> This logic sounds complicated to me. I'm afraid that FDW developers may a bit
> easily misunderstand the logic and make the bug in their FDW.
> Isn't it simpler to just disable the timeout in core whenever the transaction ends
> whether committed or aborted, like statement_timeout is disabled after each
> command? For example, call something like DisableForeignCheckTimeout() in
> CommitTransaction() etc.
Your idea is that stop the timer at the end of each transactions, right?
I had not adopted that because I thought some developers might want not to stop the timer
even if transactions ends. It caused complexed situation and not have good usecase, however,
so your logic was implemented.
> > You are right. I think this suggests that error-reporting should be done in the
> core layer.
> > For meaningful error reporting, I changed a callback specification
> > that it should return ForeignServer* which points to downed remote server.
>
> This approach seems to assume that FDW must manage all the ForeignServer
> information so that the callback can return it. Is this assumption valid for all the
> FDW?
Not sure, the assumption might be too optimistic.
mysql_fdw can easily return ForeignServer* because it caches serverid,
but dblink and maybe oracle_fdw cannot.
> How about making FDW trigger a query cancel interrupt by signaling SIGINT to
> the backend, instead?
I understood that the error should be caught by QueryCancelPending.
Could you check 0003? Does it follow that?
Best Regards,
Hayato Kuroda
FUJITSU LIMITED
