From: Robert Haas [mailto:robertmhaas@gmail.com]
> But that's not what it will do. As long as the server continues to
> dribble out protocol messages from time to time, the timeout will
> never fire no matter how much time passes. I saw a system once where
> every 8kB read took many seconds to complete; such a system could
> dribble out sequential scan results over an arbitrarily long period of
> time without ever tripping the timeout.
I understood hat the example is about an SELECT that returns multiple rows. If so, statement_timeout should handle it,
shouldn'tit?
> If you really want to return
> control to the user in any situation, what you can do is use the libpq
> APIs in asynchronous mode which, barring certain limitations of the
> current implementation, will actually allow you to maintain control
> over the connection at all times.
Maybe. But the users aren't often in a situation to modify the application to use libpq asynchronous APIs.
> I think the use case for a timeout that has both false positives (i.e.
> it will fire even when there's no problem, as when the connection is
> legitimately idle) and false negatives (i.e. it will fail to trigger
> when there is a problem, as when there are periodic notices or
> notifies from the server connection) is extremely limited if not
> nonexistent, and I think the potential for users to be confused is
> really high.
My understanding is that the false positive case doesn't occur, because libpq doesn't wait on the socket while the
clientis idle and not communicating SQL request/response. As for the false negative case, resetting the timer upon
noticesor notifies receipt is good, because they show that the database server is functioning. socket_timeout is not a
mechanismto precisely limit the duration of query request/response. It is kind of a stop-gap, last resort to assure
returncontrol within reasonable amount of time, rather than minutes or hours.
Regards
Takayuki Tsunakawa