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