On 2022/01/21 15:08, kuroda.hay...@fujitsu.com wrote:
Dear Fujii-san, Zhihong,
I attached the latest version.
Thanks for updating the patch!
+int
+TryDisableRemoteServerCheckingTimeout(void)
When more than one FDWs are used, even if one FDW calls this function to
disable the timeout, its remote-server-check-callback can still be called. Is
this OK?
Please imagine the case where two FDWs are used and they registered their
callbacks. Even when one FDW calls TryDisableRemoteServerCheckingTimeout(), if
another FDW has not called that yet, the timeout is still being enabled. If the
timeout is triggered during that period, even the callback registered by the
FDW that has already called TryDisableRemoteServerCheckingTimeout() would be
called.
+ if (remote_servers_connection_check_interval > 0)
+ {
+ CallCheckingRemoteServersCallbacks();
+
enable_timeout_after(CHECKING_REMOTE_SERVERS_TIMEOUT,
+
remote_servers_connection_check_interval);
LockErrorCleanup() needs to be called before reporting the error, doesn't it?
This can cause an error even while DoingCommandRead == true. Is that safe?
The biggest change is that callbacks are no longer un-registered at the end of
transactions.
FDW developer must enable or disable timeout instead, via new APIs.
The timer will be turned on when:
* new GUC is >= 0, and
This can cause the timeout to be enabled even when no remote transaction is
started?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
