> > 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

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to