Re: [HACKERS] Support for JDBC setQueryTimeout, et al. - Mailing list pgsql-jdbc

From Tom Lane
Subject Re: [HACKERS] Support for JDBC setQueryTimeout, et al.
Date
Msg-id 4983.1286911775@sss.pgh.pa.us
Whole thread Raw
In response to Re: Support for JDBC setQueryTimeout, et al.  (David Fetter <david@fetter.org>)
List pgsql-jdbc
David Fetter <david@fetter.org> writes:
> 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*.

Actually, that seems like a fine argument why this should *not* be
implemented on the server side... although I would expect a connection
pooler to roll back GUC changes when switching users, so the argument
seems to presume several rather broken implementation decisions in
order to make the scenario possible.

> 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.

You'd need to first convince people that SET LOCAL doesn't solve the
problem well enough already.

            regards, tom lane

pgsql-jdbc by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: [HACKERS] Support for JDBC setQueryTimeout, et al.
Next
From: Radosław Smogura
Date:
Subject: Re: Support for JDBC setQueryTimeout, et al.