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 |
Date: | 2019-02-20 06:04:52 |
Message-ID: | D09B13F772D2274BB348A310EE3027C643C5A6@g01jpexmbkw24 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
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:
(1) tcp_user_timeout
(2) tcp_socket_timeout (or suggested client_statement_timeout,
send_timeout/recv_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. [1]
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. [2]
> 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
and tcp_user_timeout.
Then we can decide on the which parameter name is better once the
implementation becomes clearer.
[1] https://www.postgresql.org/docs/devel/runtime-config-client.html
[2] https://jdbc.postgresql.org/documentation/head/connect.html#connection-parameters
Regards,
Kirk Jamison
From | Date | Subject | |
---|---|---|---|
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 |