From: Robert Haas [mailto:robertmhaas@gmail.com]
> The first thing I notice about the socket_timeout patch is that the
> documentation is definitely wrong:
Agreed. I suppose the description should be clearer about:
* the purpose and what situation this timeout will help: not for canceling a long-running query or recovering from a
networkfailure.
* relationship with other timeout parameters: e.g., socket_timeout > connect_timeout, socket_timeout >
statement_timeout,socket_timeout > TCP keepalive/user timeout
> Actually, I think that socket_timeout_v8.patch is a bad idea and
> should be rejected, not because it doesn't send a cancel to the server
> but just because it's not the right way of solving either of the
> problems that it purports to solve. If you want a timeout for
> queries, you need that to be administered by the server, which knows
> when it starts and finishes executing a query; you cannot substitute a
> client-side judgement based on the last time we received a byte of
> data. Maybe a client-side judgement would work if the timer were
> armed when we send a Query or Execute message and disarmed when we
> receive ReadyForQuery. And, if you want a network problem detector,
> then you should use keepalives and perhaps the TCP_USER_TIMEOUT stuff,
> so that you don't kill perfectly good connections that just happen to
> be idle.
I think the purpose of socket_timeout is to avoid infinite or unduely long wait and return response to users, where
otherexisting timeout parameters wouldn't help. For example, OS's process scheduling or paging/swapping problems might
causelong waits before postgres gets control (e.g. due to Transparent HugePage (THP)). Within postgres, the unfair
lwlockcan unexpected long waits (I experienced dozens of seconds per wait on ProcArrayLock, which was unbelievable.)
Someonemay say that those should be fixed or improved instead of introducing this parameter, but I think it's good to
havethis as a stop-gap measure. In other words, we can suggest setting this parameter when the user asks "How can I
returncontrol to the end user in any situation?"
Regards
Takayuki Tsunakawa
