RE: Timeout parameters - Mailing list pgsql-hackers

From Nagaura, Ryohei
Subject RE: Timeout parameters
Date
Msg-id EDA4195584F5064680D8130B1CA91C453EBF12@G01JPEXMBYT04
Whole thread Raw
In response to RE: Timeout parameters  ("Jamison, Kirk" <k.jamison@jp.fujitsu.com>)
Responses RE: Timeout parameters
List pgsql-hackers
This mail is the same as https://www.postgresql.org/message-id/EDA4195584F5064680D8130B1CA91C453EBE79%40G01JPEXMBYT04
I resend because the mail didn't be reflected.

Hi, kirk-san.

> From: Nagaura, Ryohei <nagaura.ryohei@jp.fujitsu.com> This is my bad. 
> I'll remake it.
> Very sorry for the same mistake.
I remade the patches and attached in this mail.
In socket_timeout patch, I replaced "atoi" to "parse_int_param" and inserted spaces just after some comma.
There are a few changes about documentation for the following reason:

> From: Jamison, Kirk <k.jamison@jp.fujitsu.com> Got the doc fix. I 
> wonder if we need to document what effect the parameter does:
> terminating the connection. How about:
I also don't know, but...

> Controls the number of seconds of client-server communication 
> inactivity before forcibly closing the connection in order to prevent 
> client from infinite waiting for individual socket read/write 
> operations. This can be used both as a force global query timeout and 
> network problems detector, i.e. hardware failure and dead connection. A value of zero (the default) turns this off.
"communication inactivity" seems to be a little extreme.
If the communication layer is truly dead you will use keepalive.
This use case is when socket option is not available for some reason.
So it would be better "terminating the connection" in my thought.
And...

> Well, you may remove the "i.e. hardware failure and dead connection" 
> if that's not necessary.
I don't think it is necessary because you can use this parameter other than that situations.
Not "i.e." but "e.g." have a few chance to be documented.

About TCP_USER_TIMEOUT patches, there are only miscellaneous changes: removing trailing spaces and making comments of
parameterslower case as you pointed out.
 

Best regards,
---------------------
Ryohei Nagaura


Attachment

pgsql-hackers by date:

Previous
From: Dmitry Dolgov
Date:
Subject: Re: Segfault when restoring -Fd dump on current HEAD
Next
From: Michael Meskes
Date:
Subject: Re: SQL statement PREPARE does not work in ECPG