RE: Timeout parameters

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(dot)ryohei(at)jp(dot)fujitsu(dot)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(dot)jamison(at)jp(dot)fujitsu(dot)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 parameters lower case as you pointed out.

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