RE: Timeout parameters

Hello Nagaura-san.

Thank you for your response.

The main idea of my comment was to avoid handling logical errors (
"client-side timeout") in advance to the detection of network problems!!!!
Therefore, I suggested setting "client-side timeout" greater of equal to
the TCP_USER_TIMEOUT or note about it in the documentation.

> In conclusion, you think this feature should process something e.g.,
sending canceling request. Don't you?
> If yes, is it hard for you to accept my thought as follows?
> 1. The "end-user" I mentioned is application/system user.
> 2. Such end-users don't want to wait responses from system or
application for whatever reason.
> 3. End-users don't care where the failure of the system is when it
occurs.
> 4. They just don't want to wait long.
> 5. If I made the server processing something when this parameter is
triggered, they would wait for the time it takes to process it.
> 6. Therefore it is not preferable to make servers processing something
in this feature.

I see what you mean and I agree with you.

> > Such a situation looks to be covered by TCP_USER_TIMEOUT and
keep_alive
> > mechanisms.
> i.e., you mean that it can't be happened to occur OS hang with network
still alive.
> Don't you?

I'm afraid to be mistaken but I think that when network is alive it means
that OS does not hang.
I think that it is a responsibility of the OS kernel to manage network
connections. Keep_alive mechanism checks a network state by exchanging
data between client's and server's OS kernels. I think the same procedure
is used in TCP_USER_TIMEOUT mechanism. So, when keep_alive and
TCP_USER_TIMEOUT say that network works correct, it means that kernels of
client and server do not hang. On the other hand it does not guarantee
that PostgreSQL server is not hang. "client-side timeout" should handle
this problem when network problem was not detected.

Best regards,
Mikalai Keida