Re: [Proposal] Add foreign-server health checks infrastructure
| От | Fujii Masao |
|---|---|
| Тема | Re: [Proposal] Add foreign-server health checks infrastructure |
| Дата | |
| Msg-id | 2160c6db-079a-be7c-df96-6c5cb21c03cf@oss.nttdata.com обсуждение |
| Ответ на | RE: [Proposal] Add foreign-server health checks infrastructure ("kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>) |
| Ответы |
RE: [Proposal] Add foreign-server health checks infrastructure
|
| Список | pgsql-hackers |
On 2022/03/04 15:17, kuroda.hayato@fujitsu.com wrote:
> Hi Hackers,
>
>> It's not happy, but I'm not sure about a good solution. I made a timer reschedule
>> if connection lost had detected. But if queries in the transaction are quite short,
>> catching SIGINT may be fail.
>
> Attached uses another way: sets pending flags again if DoingCommandRead is true.
> If a remote server goes down while it is in idle_in_transaction,
> next query will fail because of ereport(ERROR).
>
> How do you think?
Sounds ok to me.
Thanks for updating the patches!
These failed to be applied to the master branch cleanly. Could you update them?
+ this option relies on kernel events exposed by Linux, macOS,
s/this/This
+ GUC_check_errdetail("pgfdw_health_check_interval must be set to 0 on this platform");
The actual parameter name "postgres_fdw.health_check_interval"
should be used for the message instead of internal variable name.
+ /* Register a timeout for checking remote servers */
+ pgfdw_health_check_timeout = RegisterTimeout(USER_TIMEOUT, pgfdw_connection_check);
This registered signal handler does lots of things. But that's not acceptable
and they should be performed outside signal handler. No?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: