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