Re: [JDBC] Support for JDBC setQueryTimeout, et al.

On Tue, Oct 12, 2010 at 17:55, David Fetter <david(at)fetter(dot)org> wrote:
> On Tue, Oct 12, 2010 at 10:37:00AM -0500, Kevin Grittner wrote:
>> David Fetter <david(at)fetter(dot)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/