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
