Thanks you for your response.
Database config:
shared_buffers = 8GB
temp_buffers = 32MB
work_mem = 64MB
maintenance_work_mem = 512MB
effective_cache_size = 16GB
In usual load there are not much pressure on memory, but it is possible to have all clients start using heavy reports. They are valid requests and could consume all memory. In this border and not likely but possible scenario it could be useful to let OOM killer to kill client's processes/connections but leave PostgreSQL system processes (postmaster, writer, stat, log, streaming, ...) excluded from reach of OOM killer.
On Wed, Aug 1, 2012 at 11:48 AM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
You should apply the latest bug fixes by updating to 9.1.4.
http://www.postgresql.org/support/versioning/
> with 32GB of RAM, 32GB of SWAP and during high load we could reach
> (swap + RAM) memory limit.
If you're even *starting* to swap you're doing something wrong, much
less exhausting swap space equal to actual RAM. What is your
configuration?
http://wiki.postgresql.org/wiki/Server_Configuration
While it's probably a good idea to configure the OOM killer to
behave more sanely, we tend to ignore it in favor of ensuring that
it never comes into play. We run about 200 databases 24/7 and I
think I've seen it kick in about twice -- when we ran queries that
leaked memory on each row in a big query.
-Kevin