Thread: Question about client_connection_check_interval
Dear Hackers, While reading source codes about timeouts and GUC and I found that strange behavior about client_connection_check_interval. Currently we did not an assign_hook about client_connection_check_interval, that means a timeout will not turn on immediately if users change the GUC from zero to arbitrary positive integer. In my understanding the timeout will fire only when: * before starting transaction * after firing the CLIENT_CONNECTION_CHECK_TIMEOUT timeout Hence I thought following inconvenient scenario: 1. set client_connection_check_interval = 0 in postgresql.conf 2. start a tx 3. SET LOCAL client_connection_check_interval to non-zero value in order to checking clients until the end of the tx 4. users expect to firing the timeout, but it does not work because enable_timeout_after() will never execute in the tx Is this an expected behavior? If so, I think this spec should be documented. If not, I think an assign_hook is needed for resolving the problem. How do you think? Best Regards, Hayato Kuroda FUJITSU LIMITED
Hello. At Thu, 7 Oct 2021 03:07:33 +0000, "kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com> wrote in > Dear Hackers, > > While reading source codes about timeouts and GUC and I found that > strange behavior about client_connection_check_interval. > > Currently we did not an assign_hook about client_connection_check_interval, > that means a timeout will not turn on immediately if users change the GUC > from zero to arbitrary positive integer. > In my understanding the timeout will fire only when: > > * before starting transaction You're misunderstanding here. Maybe you saw that start_xact_command() starts the timer but note that the function is called before every command execution. > * after firing the CLIENT_CONNECTION_CHECK_TIMEOUT timeout > > Hence I thought following inconvenient scenario: > > 1. set client_connection_check_interval = 0 in postgresql.conf > 2. start a tx > 3. SET LOCAL client_connection_check_interval to non-zero value > in order to checking clients until the end of the tx > 4. users expect to firing the timeout, but it does not work > because enable_timeout_after() will never execute in the tx So this is wrong. I should see the check performed as expected. That behavior would be clearly visualized if you inserted an elog() into pq_check_connection(). > Is this an expected behavior? If so, I think this spec should be documented. > If not, I think an assign_hook is needed for resolving the problem. > > How do you think? And it seems that the documentation describes the behavior correctly. https://www.postgresql.org/docs/14/runtime-config-connection.html > client_connection_check_interval (integer) > > Sets the time interval between optional checks that the client is > still connected, while running queries. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
At Fri, 08 Oct 2021 09:56:32 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in > Hello. > > At Thu, 7 Oct 2021 03:07:33 +0000, "kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com> wrote in > > Dear Hackers, > > > > While reading source codes about timeouts and GUC and I found that > > strange behavior about client_connection_check_interval. > > > > Currently we did not an assign_hook about client_connection_check_interval, > > that means a timeout will not turn on immediately if users change the GUC > > from zero to arbitrary positive integer. > > In my understanding the timeout will fire only when: > > > > * before starting transaction > > You're misunderstanding here. Maybe you saw that start_xact_command() > starts the timer but note that the function is called before every > command execution. > > > * after firing the CLIENT_CONNECTION_CHECK_TIMEOUT timeout > > > > Hence I thought following inconvenient scenario: > > > > 1. set client_connection_check_interval = 0 in postgresql.conf > > 2. start a tx > > 3. SET LOCAL client_connection_check_interval to non-zero value > > in order to checking clients until the end of the tx > > > 4. users expect to firing the timeout, but it does not work > > because enable_timeout_after() will never execute in the tx > > So this is wrong. I should see the check performed as expected. That I don't come up with how come I wrote this, but the "*I* should" is, of course, a typo of "*You* should". So this is wrong. You should see the check performed as expected. That > behavior would be clearly visualized if you inserted an elog() into > pq_check_connection(). > > > Is this an expected behavior? If so, I think this spec should be documented. > > If not, I think an assign_hook is needed for resolving the problem. > > > > How do you think? > > And it seems that the documentation describes the behavior correctly. > > https://www.postgresql.org/docs/14/runtime-config-connection.html > > > client_connection_check_interval (integer) > > > > Sets the time interval between optional checks that the client is > > still connected, while running queries. -- Kyotaro Horiguchi NTT Open Source Software Center
Dear Horiguchi-san, Thank you for replying! I understood I was wrong. Sorry. > You're misunderstanding here. Maybe you saw that start_xact_command() > starts the timer but note that the function is called before every > command execution. Based on your advice I read codes again and I found that start_xact_command() is called from exec_XXX functions. They are called when backend processes read first char from front-end, hence I agreed enable_timeout_after() will call very quickly if timeout is disabled. > So this is wrong. I should see the check performed as expected. That > behavior would be clearly visualized if you inserted an elog() into > pq_check_connection(). Right. As mentioned above timeout is checked basically whenever reading commands. I embedded elog() to ClientCheckTimeoutHandler() and visualized easily. > And it seems that the documentation describes the behavior correctly. > > https://www.postgresql.org/docs/14/runtime-config-connection.html > > > client_connection_check_interval (integer) > > > > Sets the time interval between optional checks that the client is > > still connected, while running queries. Yeah I agreed that, I apologize for mistaking source and doc analysis. Best Regards, Hayato Kuroda FUJITSU LIMITED