From: Robert Haas [mailto:robertmh...@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't it? > 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 client is idle and not communicating SQL request/response. As for the false negative case, resetting the timer upon notices or notifies receipt is good, because they show that the database server is functioning. socket_timeout is not a mechanism to precisely limit the duration of query request/response. It is kind of a stop-gap, last resort to assure return control within reasonable amount of time, rather than minutes or hours. Regards Takayuki Tsunakawa
