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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Support for JDBC setQueryTimeout, et al.
Дата
Msg-id 4983.1286911775@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Support for JDBC setQueryTimeout, et al.  (David Fetter <david@fetter.org>)
Список 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 по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: [HACKERS] Support for JDBC setQueryTimeout, et al.
Следующее
От: Radosław Smogura
Дата:
Сообщение: Re: Support for JDBC setQueryTimeout, et al.