On Saturday, March 16, 2019 5:40 PM (GMT+9), Fabien COELHO wrote:
> > Fabien, I was wondering whether you can apply TCP_USER_TIMEOUT patch
> > and continue discussion about 'socket_timeout'?
> I can apply nothing, I'm just a small-time reviewer.
> Committers on the thread are Michaël-san and Robert, however I'm not sure
> that they are very sensitive to "please apply this patch" requests: they
> are the lone judges of their own priorities.
Regarding user timeout parameters:
Based from previous reviews of the code (it seems good) and reviewers'
comments, everyone seems to agree that user timeout parameters are
needed, so we can just waitfor the updated patch.
The author, Nagaura-san, has gotten feedback from Robert for the doc part.
So if an updated patch is posted with addressed comments, then I think we
can review it again for the final round.
---
As for socket_timeout parameters:
The use case for socket timeout parameter is that it's a stop-gap approach
to prevent applications from infinite waiting for the DB server when other
timeout parameters such as keepalives and tcp_user_timeout fail to detect
the connection error. (That's why I thought it's a network problem detector?)
The main argument here is about the security risk of allowing socket timeout
to cancel valid connections, right? Then to address that, I agree with
Tsunakawa-san to document that the value should at least be (equal? or) higher
than the other timeout parameters.
If documenting is not enough, then we can limit that within the code by making
sure that socket_timeout value must be greater than the other timeout parameters
(keepalives, tcp user timeout, statement timeout, etc.). Otherwise, socket_timeout
parameter should not work even if was switched on. Or is that too much enforcing?
Regards,
Kirk Jamison