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
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
In response to
pgsql-admin by date
|Next:||From: Gerhard Hintermayer||Date: 2011-04-28 14:38:47|
|Subject: index usage on timestamp without time zone|
|Previous:||From: Adrian Klaver||Date: 2011-04-28 14:29:52|
|Subject: Re: plpython module import errors|
pgsql-bugs by date
|Next:||From: Brian S. Krug||Date: 2011-04-28 19:33:13|
|Subject: BUG #5996: CURRENT_TIMESTAMP uses often undesired TRANSACTION_TIMESTAMP, instead of STATEMENT_TIMESTAMP|
|Previous:||From: Carlo Curatolo||Date: 2011-04-28 10:31:02|
|Subject: Re: BUG #5800: "corrupted" error messages (encoding problem ?)|