Re: select on 22 GB table causes "An I/O error occured while sending to the backend." exception

david(at)lang(dot)hm 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