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.