* Radosław Smogura (rsmog...@softperience.eu) wrote: > > To me, that sounds like a bug in the connection pooler. It is only > > safe under quite limited circumstances. > > It's hard to say this is bug. The GF connection pooler is "general pooler" > for all drivers, so it can't know anything about reseting, and if I have > right JDBC4 doesn't support such notifications. It can't close logical > connections, as if would close, cached statements will be invalideted too.
If it can't figure out a way to issue a command in between handing
around a connection to different clients then, yeah, I'd call it a bug
that needs to be fixed. Maybe other systems don't need it, and it can
be a no-op there, but the capability certainly needs to be there.
> 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 :( ).
Thanks,
Stephen
signature.asc
Description: Digital signature
