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