RE: Timeout parameters

Hello, Mikalai-san.

Thank you for your mail.

> From: MikalaiKeida(at)ibagroup(dot)eu <MikalaiKeida(at)ibagroup(dot)eu>
> I'm with Fabien that "client-side timeout" seems unsafe. Also I agree with Fabien
> that quire can take much time to be processed by the PosgtreSQL server and it is
> a normal behavior. There is possible that performance of the PostgreSQL server
> machine can be low temporary or continuously, especially during upgrading
> procedure.
I'm very poor at English, so I couldn't read your intension.
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.

> 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?

These comments are helpful for documenting. Thank you.
> I think it is important to add some more information into the description of this
> parameter which informs end-users that this parameter has to be used very
> carefully because it can impact as on the client application as on the server.
>...
> May be it is better to warn in documentation or prohibit in the source
> code to set "client-side timeout" less than TCP_USER_TIMEOUT to avoid handling
> "possible" logical problems ahead to the network problems.
> Keep in mind that "client-side timeout" can abort a connection which uses
> UNIX-domain sockets too.
I didn't take into account it. I'll investigate it. Thanks.

Best regards,
---------------------
Ryohei Nagaura