RE: Timeout parameters

mikalaikeida@ibagroup.eu

From: MikalaiKeida@ibagroup.eu
To: "Nagaura, Ryohei" <nagaura.ryohei@jp.fujitsu.com>
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>, "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgresql.org>, "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
Date: 2019-03-11T09:07:11Z
Lists: pgsql-hackers
Hello Ryohei-san,

I understand the main aim of your suggestion that a client application has 
to do a lot of work except making quires to the database. I agree with you 
that "client-side timeout" has to be integrated into the PostgreSQL server 
and libpq.
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 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.

> You mentioned about when a SQL query is heavy, but I want to talk about 
when OS hang.
> If OS hang occurs, the cost of cancel request processing is so high.

Such a situation looks to be covered by TCP_USER_TIMEOUT and keep_alive 
mechanisms. 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.

What do you think about it?

Best regards,
Mikalai Keida

Commits

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