max_connections proposal - Mailing list pgsql-general

From Craig Ringer
Subject max_connections proposal
Date
Msg-id 4DDDC1CD.3010600@postnewspapers.com.au
Whole thread Raw
Responses Re: max_connections proposal  (Merlin Moncure <mmoncure@gmail.com>)
Re: max_connections proposal  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: max_connections proposal  (Greg Smith <greg@2ndQuadrant.com>)
Re: max_connections proposal  (Edison So <edison.so2@gmail.com>)
List pgsql-general
There might be a very cheap and simple way to help reduce the number of
people running into problems because they set massive max_connections
values that their server cannot cope with instead of using pooling.

In the default postgresql.conf, change:

max_connections = 100                   # (change requires restart)
# Note:  Increasing max_connections costs ~400 bytes of shared memory
# per connection slot, plus lock space (see max_locks_per_transaction).

to:

max_connections = 100                   # (change requires restart)
# WARNING: If you're about to increase max_connections above 100, you
# should probably be using a connection pool instead. See:
#     http://wiki.postgresql.org/max_connections
#
# Note:  Increasing max_connections costs ~400 bytes of shared memory
# per connection slot, plus lock space (see max_locks_per_transaction).
#


... where wiki.postgresql.org/max_connections (which doesn't yet exist)
explains the throughput costs of too many backends and the advantages of
configuring a connection pool instead.

Sure, this somewhat contravenes the "users don't read - ever" principle,
but we can hope that _some_ people will read a comment immediately
beside the directive they're modifying.

--
Craig Ringer

pgsql-general by date:

Previous
From: Craig Ringer
Date:
Subject: Re: PostgreSQL 8.4.8 bringing my website down every evening
Next
From: Merlin Moncure
Date:
Subject: Re: PostgreSQL 8.4.8 bringing my website down every evening