[EMAIL PROTECTED] wrote: > On Wed, 27 Aug 2008, Andrew Sullivan wrote: >>> seperate copies for the seperate processes (and if at this time it runs of >>> of memory it invokes the OOM killer to free some space), >> >> . . .it kills processes that are using a lot of memory. Those are not >> necessarily the processes that are allocating memory they don't need. > > the bahavior of the OOM killer has changed over time, so far nobody has > been able to come up with a 'better' strategy for it to follow.
The problem with OOM killer for Postgres is that it tends to kill the postmaster. That's really dangerous. If it simply killed a backend then it wouldn't be so much of a problem. Some time ago I found that it was possible to fiddle with a /proc entry to convince the OOM to not touch the postmaster. A postmaster with the raw IO capability bit set would be skipped by the OOM too killer (this is an Oracle tweak AFAIK). These are tricks that people could use in their init scripts to protect themselves. (I wonder if the initscript supplied by the RPMs or Debian should contain such a hack.) -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
