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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-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

Browse pgsql-admin by date

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

Browse pgsql-bugs by date

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