Skip site navigation (1) Skip section navigation (2)

Re: BUG #5995: connection pooling not working

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Suprabhat Mohapatra" <suprabhatm(at)gmail(dot)com>
Cc: <pgsql-admin(at)postgresql(dot)org>
Subject: Re: BUG #5995: connection pooling not working
Date: 2011-04-28 14:37:59
Message-ID: 4DB93577020000250003CFE6@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-bugs
Please keep the list copied.  I'm moving this to the pgsql-admin
list (with a blind copy to -bugs), since there is really no hint of
a PostgreSQL bug here, except possibly in terms of how we document
this issue.
 
 
Suprabhat Mohapatra <suprabhatm(at)gmail(dot)com> wrote:
 
> Should I send you the sample code that we are using.
 
That's unlikely to help much.
 
You either need to really boost max_connections or (much better)
properly configure some connection pooler.  There are many options
for the latter.  I'm told that Tomcat comes with a good connection
pooler built in.  If you're in an environment where the software
comes with a connection pooler, that is often the best way to go. 
Otherwise, pgbouncer and pgpool both have their fans.  I've looked
over the stand-alone JDBC pooler that Apache has, and it looked
pretty good, too.
 
The key is read the documentation carefully, and understand that the
pooler can accept 300 client connections to it (or whatever number
you need) and service those with a much smaller set of database
connections.  If you're configuring the pooler to use as many
database connections as you have clients, you're missing the point.
 
> I am on a production system and we have reached a stage where we
> may lose the business if this is not done in this week.
 
You might want to contact one of the many organizations which
provide contract support for PostgreSQL.  I'm pretty sure most or
all of them will have someone with experience configuring a good
connection pooler.
 
http://www.postgresql.org/support/professional_support
 
-Kevin

In response to

pgsql-admin by date

Next:From: Gerhard HintermayerDate: 2011-04-28 14:38:47
Subject: index usage on timestamp without time zone
Previous:From: Adrian KlaverDate: 2011-04-28 14:29:52
Subject: Re: plpython module import errors

pgsql-bugs by date

Next:From: Brian S. KrugDate: 2011-04-28 19:33:13
Subject: BUG #5996: CURRENT_TIMESTAMP uses often undesired TRANSACTION_TIMESTAMP, instead of STATEMENT_TIMESTAMP
Previous:From: Carlo CuratoloDate: 2011-04-28 10:31:02
Subject: Re: BUG #5800: "corrupted" error messages (encoding problem ?)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group