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

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