Question about client_connection_check_interval

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