RE: Timeout parameters - Mailing list pgsql-hackers

From Tsunakawa, Takayuki
Subject RE: Timeout parameters
Date
Msg-id 0A3221C70F24FB45833433255569204D1FBC4191@G01JPEXMBYT05
Whole thread Raw
In response to Re: Timeout parameters  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Timeout parameters
Re: Timeout parameters
List pgsql-hackers
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





pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: pgsql: Add support for hyperbolic functions, as well aslog10().
Next
From: David Rowley
Date:
Subject: Re: Tid scan improvements