From: MikalaiKeida@ibagroup.eu [mailto:MikalaiKeida@ibagroup.eu]
> Do you mind me asking you whether you have thought that solving your problem
> can lead to the problem in the other user applications?
> Let's imagine a possible problem:
> 1. end-user sets 'socket_timeout' only for current session
> 2. 'socket_timeout' is much shorter than 'keep_alive', 'tcp_user_timeout'
> and 'statement_timeout'
> 3. end-user invokes a 'heavy' query which is not be possible to process
> by PostgreSQL server within 'socket_timeout'
> 4. if the query fails due to timeout, terminate the session and repeat it
>
> As the query is not cancelled, PostgreSQL server will process it till
> completion or 'statement_timeout' expiration. In such a case PostgreSQL
> server can be overloaded by an 'unreliable' user/users and other end-users
> will not be able to work with PostgreSQL server as they expected.
Yes, so I think it would be necessary to describe how to set socket_timeout with relation to other timeout parameters
--socket_timeout > statement_timeout, emphasizing that socket_timeout is not for canceling long-running queries but for
returningcontrol to the client.
Regards
Takayuki Tsunakawa
