Re: configurability of OOM killer

* Tom Lane:

>> How much does that help? Postmaster &c still need to be shut down
>> when a regular backend dies due to SIGKILL.
>
> The $64 problem is that if the parent postmaster process is victimized
> by the OOM killer, you won't get an automatic restart.

The classic answer to that is to put it into inittab. 8-/

> In most people's eyes that is considerably worse than the momentary
> DOS imposed by a kill of a child backend. And what we now find,
> which is truly staggeringly stupid on the kernel's part, is that it
> *preferentially* kills the parent instead of whatever child might
> actually be eating the memory.

IIRC, the idea is to get the machine out of OOM land with one killed
process, even if it causes dependent processes to fail. No matter
what you do at this point, you lose. If you prefer the child instead
of the parent, the parent might just reattempt the fork() (which
succeeds thanks to COW), and the child runs into the same OOM
condition.

--
Florian Weimer <fweimer(at)bfk(dot)de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99