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 по дате отправления: