Re: [Proposal] Add foreign-server health checks infrastructure - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: [Proposal] Add foreign-server health checks infrastructure
Date
Msg-id be053d3d-b195-0852-4c29-0c67bb640b48@oss.nttdata.com
Whole thread Raw
In response to RE: [Proposal] Add foreign-server health checks infrastructure  ("kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>)
Responses RE: [Proposal] Add foreign-server health checks infrastructure  ("kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>)
Re: [Proposal] Add foreign-server health checks infrastructure  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers

On 2022/02/01 13:37, kuroda.hayato@fujitsu.com wrote:
> Dear Fujii-san,
> 
> Thank you for reviewing! I attached the latest version.

Thanks!

> Indeed and it should be avoided. I added a counter to CheckingRemoteServersCallbackItem.
> The register function returns the registered item, and it must be set as the argument for
> enable and disable functions.
> Callback functions will be called when item->counter is larger than zero.

This logic sounds complicated to me. I'm afraid that FDW developers may a bit easily misunderstand the logic and make
thebug in their FDW.
 

Isn't it simpler to just disable the timeout in core whenever the transaction ends whether committed or aborted, like
statement_timeoutis disabled after each command? For example, call something like DisableForeignCheckTimeout() in
CommitTransaction()etc.
 

> 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?
 

How about making FDW trigger a query cancel interrupt by signaling SIGINT to the backend, instead?

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: dynamic result sets support in extended query protocol
Next
From: Andy Fan
Date:
Subject: Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?