> > I don't know what you are exactly referring to in above URL
> > when you are talking about "potential pitfalls of pooling".
> > Please explain more.
>
> Sorry, I wasn't implying that pgpool doesn't deal with the issues, just that
> some people aren't necessarily aware of them up front. For instance, pgpool
> does an 'abort transaction' and a 'reset all' in lieu of a full reconnect
> (of course, since a full reconnect is exactly what we are trying to avoid).
> Is this is enough to guarantee that a given pooled connection behaves
> exactly as a non-pooled connection would from a client perspective? For
> instance, temporary tables are usually dropped at the end of a session, so a
> client (badly coded perhaps) that does not already use persistent
> connections might be confused when the sequence 'connect, create temp table
> foo ..., disconnect, connect, create temp table foo ...' results in the
> error 'Relation 'foo' already exists'.
First, it's not a particular problem with pgpool. As far as I know any
connection pool solution has exactly the same problem. Second, it's
easy to fix if PostgreSQL provides a functionarity such as:"drop all
temporary tables if any". I think we should implement it if we agree
that connection pooling should be implemented outside the PostgreSQL
engine itself. I think cores agree with this.
--
Tatsuo Ishii
