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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Support for JDBC setQueryTimeout, et al.
Дата
Msg-id 20260.1287153534@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Support for JDBC setQueryTimeout, et al.  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: [HACKERS] Support for JDBC setQueryTimeout, et al.
Re: [HACKERS] Support for JDBC setQueryTimeout, et al.
Список pgsql-jdbc
Stephen Frost <sfrost@snowman.net> writes:
> * Radosław Smogura (rsmogura@softperience.eu) wrote:
>> But benefits of pooling statements are much more greater then RESET ALL,
>> because you can take advance of precompiling prepared statements,
>> increasing performance; it is comparable to using connection pool instead
>> of starting physical connections.

> errr, I don't believe RESET ALL touches cache'd plans and whatnot (which
> is actually a problem I've run into in the past, because changing the
> search_path also doesn't invalidate plans, and neither does set role, so
> you end up with cache'd plans that try to hit things you don't have
> permissions to any more :( ).

Yeah, actually what you need is DISCARD ALL when reassigning a
connection to another client.  Anything less than that assumes the
clients are cooperating closely, ie they *want* the same prepared
statements etc.  But even if you make that assumption, a pooler that
isn't even capable of sending an ABORT between clients doesn't seem
usable to me.  For example, if a client loses its network connection
mid-transaction, that failure will cascade to other clients if you
don't have any ability to reset the database session before handing
it to another client.

            regards, tom lane

В списке pgsql-jdbc по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Support for JDBC setQueryTimeout, et al.
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: [HACKERS] Support for JDBC setQueryTimeout, et al.