Hi, Tsunakawa-san
Thank you for your comments.
On Wed, Feb 20, 2019 at 5:56 PM, Tsunakawa, Takayuki wrote:
> > Perhaps you could also clarify a bit more through documentation on how
> > socket_timeout handles the timeout differently from statement_timeout
> > and tcp_user_timeout.
> Maybe. Could you suggest good description?
Clients wait until the socket become readable when they try to get results of their query.
If the socket state get readable, clients read results.
(See src/interfaces/libpq/fe-exec.c, fe-misc.c)
The current pg uses poll() to monitor socket states.
"socket_timeout" is used as timeout argument of poll().
(See [1] about poll() and its arguments)
Because "tcp_user_timeout" handles the timeout before and after the above procedure,
there are different monitoring target between "socket_timeout" and "tcp_user_timeout".
When the server is saturated, "statement_timeout" doesn't work while "socket_timeout" does work.
In addition to this, the purpose of "statement_timeout" is to reduce server's burden, I think.
My proposal is to enable clients to release their resource which is used communication w/ the saturated server.
On Wed, Feb 20, 2019 at 7:10 PM, Tsunakawa, Takayuki wrote:
> a) is not always accurate, because libpq is also used in the server. For example,
> postgres_fdw and WAL receiver in streaming replication.
I didn't take that possibility into consideration.
Certainly, a) is bad.
> I'm OK with either the current naming or b). Frankly, I felt a bit strange when I
> first saw the keepalive parameters, wondering why the same names were not
> chosen.
I will refer to it and wait for opinion of the reviewer.
[1] http://man7.org/linux/man-pages/man2/poll.2.html
Best regards,
---------------------
Ryohei Nagaura