Re: [JDBC] Support for JDBC setQueryTimeout, et al.
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: Radosław Smogura <rsmogura@softperience.eu>, Magnus Hagander <magnus@hagander.net>, David Fetter <david@fetter.org>, Kevin Grittner <Kevin.Grittner@wicourts.gov>, PG Hackers <pgsql-hackers@postgresql.org>, PostgreSQL JDBC List <pgsql-jdbc@postgresql.org>, robertmhaas@gmail.com
Date: 2010-10-15T14:38:54Z
Lists: pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes: > * Radosaw 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