RE: Timeout parameters - Mailing list pgsql-hackers

From Jamison, Kirk
Subject RE: Timeout parameters
Date
Msg-id D09B13F772D2274BB348A310EE3027C643E30D@g01jpexmbkw24
Whole thread Raw
In response to RE: Timeout parameters  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Responses RE: Timeout parameters  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
List pgsql-hackers
On Friday, February 22, 2019 9:46 AM (GMT+9), Tsunakawa, Takayuki wrote:

> > Terminate any session that has been idle for more than the 
> > specified number of seconds 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.
>
> Looks better than the original one.  However,
> 
> * The unit is not millisecond, but second.
> * Doesn't restart the session.
> * Choose words that better align with the existing libpq parameters.
>     e.g. "connection" should be used instead of "session" as in 
>     keepalive_xxx parameters, because there's not a concept of database
>     session at socket level.
> * Indicate that the timeout is for individual socket operations.

My bad. I was looking at the wrong documentations, so seconds should be used.
I guess we should just choose socket_timeout as parameter name.


socket_timeout (integer)

Terminate any connection that has been inactive for more than the specified number of seconds to prevent client from
infinitewaiting for individual socket read operations due to dead connection. This can be used both as a force global
querytimeout and network problems detector. A value of zero (the default) turns this off.
 

or

Controls the number of seconds of connection inactivity to prevent client from infinite waiting for individual socket
readoperations 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. 
 
    

Regards,
Kirk Jamison


pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: [HACKERS] Restricting maximum keep segments by repslots
Next
From: David Rowley
Date:
Subject: Re: pg_dump multi VALUES INSERT