RE: Timeout parameters - Mailing list pgsql-hackers
From | Jamison, Kirk |
---|---|
Subject | RE: Timeout parameters |
Date | |
Msg-id | D09B13F772D2274BB348A310EE3027C643C5A6@g01jpexmbkw24 Whole thread Raw |
In response to | RE: Timeout parameters ("Nagaura, Ryohei" <nagaura.ryohei@jp.fujitsu.com>) |
Responses |
RE: Timeout parameters
RE: Timeout parameters |
List | 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
pgsql-hackers by date: