From: mikalaike...@ibagroup.eu [mailto:mikalaike...@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 returning control to the client. Regards Takayuki Tsunakawa
