On Tue, Oct 12, 2010 at 17:55, David Fetter <david@fetter.org> wrote:
> On Tue, Oct 12, 2010 at 10:37:00AM -0500, Kevin Grittner wrote:
>> David Fetter <david@fetter.org> wrote:
>> > Is there something incomplete about the ones I sent, and if so,
>> > what?
>>
>> Well, I'm still curious why it was necessary to modify the server
>> side to implement an interface feature for which everything needed
>> seems to be present on the client side.
>
> Not everything is.
>
> Let's imagine you have a connection pooler with two clients, A and B.
> A calls setQueryTimeout, then starts a query, which terminates in
> time, but dies before handling it. B connects to the pool, gets A's
> connection, and finds a statement_timeout that's not the default, even
> though only A's single query was supposed to have that
> statement_timeout. This is not a situation that can be resolved
> without being able to set a timer *on the server side*.
Sure it can. The connection pooler just needs to issue a RESET ALL
statement when it hands over a connection from one client to another.
Isn't that what for example pgbouncer does - at least when configured
per instructions?
Also, doesn't this affect *all* settings, not just timeout, if it
doesn't? Imagine client A executing a SET datestyle for example.
AFAICS, any connection pooler that *doesn't* issue a reset between
handing this around is broken, isn't it?
>> If so, we should probably have an implementation in some other
>> interface to confirm that the server-side support fits. If not, why
>> touch the server side code at all?
>
> See above.
>
> While I'd *like* to put in a whole infrastructure for setting GUCs on
> a per-statement basis, I don't believe that we need to get out that
> giant sledgehammer for this case, even though it's worth solving.
We don't usually put in fixes for just one out of 105 cases, do we?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
