Hi, Kirk-san.
Thank you for summarizing this thread.
On Tue, Feb 19, 2019 at 6:05 PM, Jamison, Kirk wrote:
> 1) tcp_user_timeout parameter
> As for user_timeout param, there seems to be a common agreement with regards
> to its need.
> I think this can be "committed" separately when it's finalized.
I also recognize so.
BTW, tcp_user_timeout parameter of servers and clients have same name in my current implementation.
I think it would be better different name rather than same name.
I'll name them as the following a) or b):
a) server_tcp_user_timeout and client_tcp_user_timeout
b) tcp_user_timeout and user_timeout
b) is the same as the naming convention of keepalive, but it is not user-friendly.
Do you come up with better name?
Or opinion?
> (2) tcp_socket_timeout (or suggested client_statement_timeout,
> send_timeout/recv_timeout)
> 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.
* The following use case is somewhat different from those listed first. Sorry.
Use case:
1) A client query to the server and the statement is delivered correctly.
2) The server become saturated.
3) But the network layor is alive.
Because of 1), tcp_user_timeout doesn't work.
Because of 2), statement_timeout doesn't work.
Because of 3), keepalive doesn't work.
In the result, clients can't release their resource despite that they want.
My suggestion is this solution.
To limit user waiting time in pqWait(), I implemented some same logic of pqWaitTimed().
Best regards,
---------------------
Ryohei Nagaura