|From:||"Jamison, Kirk" <k(dot)jamison(at)jp(dot)fujitsu(dot)com>|
|To:||"Nagaura, Ryohei" <nagaura(dot)ryohei(at)jp(dot)fujitsu(dot)com>|
|Cc:||'Michael Paquier' <michael(at)paquier(dot)xyz>, "AYahorau(at)ibagroup(dot)eu" <AYahorau(at)ibagroup(dot)eu>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, 'Fabien COELHO' <coelho(at)cri(dot)ensmp(dot)fr>, "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>, "MikalaiKeida(at)ibagroup(dot)eu" <MikalaiKeida(at)ibagroup(dot)eu>|
|Subject:||RE: Timeout parameters|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
I tried to re-read the whole thread.
Based from what I read, there are two proposed timeout parameters,
which I think can be discussed and commited separately:
(2) tcp_socket_timeout (or suggested client_statement_timeout,
Regarding the use-case of each parameter, Tsunakawa-san briefly
explained them above. Quoting again:
> * TCP keepalive and TCP user (retransmission) timeout: for network problems
> * statement_timeout: for long-running queries
> * socket_timeout (or send/recv_timeout): for saturated servers
The already existing statement_timeout mainly limits how long
each statement should run. 
However, even if statement_timeout was configured, it does not
handle the timeout for instances that a network failure occurs,
so the application would not recover from error.
Therefore, there's a need for these features, to meet the cases
that statement_timeout currently does not handle.
1) tcp_user_timeout parameter
As for user_timeout param, there seems to be a common agreement
with regards to its need.
Just minor nitpick:
+ char *tcp_user_timeout; /* TCP USER TIMEOUT */
I think that's unnecessary capitalization in the user timeout part.
The latest tcp_user_timeout patch seems to be almost in good shape,
feedback about doc (clearer description from Andrei)
and code (whitespace, C-style, parse_int_param, handling old kernel
version) were addressed.
I think this can be "committed" separately when it's finalized.
2) tcp_socket_timeout parameter
On the other hand, there needs to be a further discussion and design
improvement with regards to the implementation of socket_timeout:
- whether (a) it should abort the connection from pqWait() or
other means, or (b) cancel the statement similar to how psql
does it as suggested by Fabien
- proper parameter name
Based from your description below, I agree with Fabien that it's somehow
the application/client side query timeout
> "socket_timeout" is the application layer timeout parameter from when
> frontend issues SQL query to when frontend receives the execution result
> from backend. When this parameter is active and timeout occurs, frontend
> close the socket. It is a merit for client to set the maximum time to
> wait for SQL.
In PgJDBC, it serves two purpose though: query timeout and network problem
detection. The use of socketTimeout aborts the connection. 
> The timeout value used for socket read operations. If reading from
> the server takes longer than this value, the connection is closed.
> This can be used as both a brute force global query timeout and a
> method of detecting network problems. The timeout is specified in
> seconds and a value of zero means that it is disabled.
Perhaps you could also clarify a bit more through documentation on how
socket_timeout handles the timeout differently from statement_timeout
Then we can decide on the which parameter name is better once the
implementation becomes clearer.
|Next Message||Michael Paquier||2019-02-20 06:08:32||Re: [PATCH][PROPOSAL] Add enum releation option type|
|Previous Message||Michael Paquier||2019-02-20 05:56:27||Re: BUG #15572: Misleading message reported by "Drop function operation" on DB with functions having same name|