From: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
---|---|
To: | 'Robert Haas' <robertmhaas(at)gmail(dot)com> |
Cc: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, "Nagaura, Ryohei" <nagaura(dot)ryohei(at)jp(dot)fujitsu(dot)com>, "Jamison, Kirk" <k(dot)jamison(at)jp(dot)fujitsu(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, "AYahorau(at)ibagroup(dot)eu" <AYahorau(at)ibagroup(dot)eu>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "MikalaiKeida(at)ibagroup(dot)eu" <MikalaiKeida(at)ibagroup(dot)eu> |
Subject: | RE: Timeout parameters |
Date: | 2019-03-14 03:33:20 |
Message-ID: | 0A3221C70F24FB45833433255569204D1FBC4191@G01JPEXMBYT05 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
From: Robert Haas [mailto:robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2019-03-14 03:46:11 | Re: Tid scan improvements |
Previous Message | Kyotaro HORIGUCHI | 2019-03-14 03:30:00 | Re: pgsql: Add support for hyperbolic functions, as well as log10(). |