Horton

RE: Timeout parameters

Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com>

View thread View on postgr.es
From: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
To: "MikalaiKeida@ibagroup.eu" <MikalaiKeida@ibagroup.eu>
Cc: "AYahorau@ibagroup.eu" <AYahorau@ibagroup.eu>, Fabien COELHO <coelho@cri.ensmp.fr>, "Jamison, Kirk" <k.jamison@jp.fujitsu.com>, "Michael Paquier" <michael@paquier.xyz>, "Nagaura, Ryohei" <nagaura.ryohei@jp.fujitsu.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>
Date: 2019-03-15T02:23:48Z
Lists: pgsql-hackers 
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 returning control to the client.


Regards
Takayuki Tsunakawa

Commits

  1. Add support TCP user timeout in libpq and the backend server