RE: Timeout parameters

From: "Jamison, Kirk" <k(dot)jamison(at)jp(dot)fujitsu(dot)com>
To: "MikalaiKeida(at)ibagroup(dot)eu" <MikalaiKeida(at)ibagroup(dot)eu>
Cc: "AYahorau(at)ibagroup(dot)eu" <AYahorau(at)ibagroup(dot)eu>, 'Fabien COELHO' <coelho(at)cri(dot)ensmp(dot)fr>, 'Michael Paquier' <michael(at)paquier(dot)xyz>, "Nagaura, Ryohei" <nagaura(dot)ryohei(at)jp(dot)fujitsu(dot)com>, "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
Subject: RE: Timeout parameters
Date: 2019-02-22 00:30:37
Message-ID: D09B13F772D2274BB348A310EE3027C643E268@g01jpexmbkw24
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


> > tcp_socket_timeout (integer)
> >
> > Terminate and restart any session that has been idle for more than
> > the specified number of milliseconds to prevent client from infinite
> > waiting for server due to dead connection. This can be used both as
> > a brute force global query timeout and detecting network problems.
> > A value of zero (the default) turns this off.

On Friday, February 22, 2019 12:01 AM (GMT+9), MikalaiKeida(at)ibagroup(dot)eu<mailto:MikalaiKeida(at)ibagroup(dot)eu>
> I am not very familiar with the PostgreSQL source code. Nevertheless,
> the main idea of this parameter is clear for me - closing a connection
> when the PostgreSQL server does not response due to any reason. However,
> I have not found in the discussion a reference that this parameter can
> be applied to the TCP as well as to the UNIX-domain sockets. Moreover,
> this parameter works out of communication layer. When we consider TCP
> communication, the failover is covered by keep_alive and tpc_user_timeout
> parameters.
> According to it, we should not use 'tcp' prefix in this parameter name,
> 'socket' sub string is not suitable too.
> 'timeout' is OK.
> This parameter works on the client side. So the word 'client' is a good
> candidate for using in this parameter name.
> This parameter affects only when we send a 'query' to the pg server.

#Shookedt. Yeah, there should be no “tcp”in that parameter, so it was
my mistake.
Regarding whether we use the “socket_timeout” or “client_query_timeout”,
why is socket not suitable?
Although I’m not arguing against client_query_timeout as it’s also
a good candidate parameter name.

> Based on it, we can build a name for this parameter 'client_query_timeout'.
> The suggested explanation of this parameter does not follow the aim of
> integrating this parameter:
> client_query_timeout
> Specifies the number of seconds to prevent client from infinite waiting
> for server acknowledge to the sent query due to dead connection. This
> can be used both as a force global query timeout and network problems
> detector. A value of zero (the default) turns this off.

Thanks for the fix. In the client side though, other parameters are specified
in milliseconds, so I used the same.

Kirk Jamison

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-02-22 00:30:49 Re: boolean and bool in documentation
Previous Message Tom Lane 2019-02-22 00:25:12 Re: Removing unneeded self joins