Re: configurability of OOM killer

Florian Weimer <fweimer(at)bfk(dot)de> writes:
> * Tom Lane:
>> 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-/

Except that no standard services are actually run that way, for
sundry good-n-sufficient reasons.

>> 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.

You're just parroting the reasoning given on the cited webpage, which
is loony because it takes no account whatsoever of actual practice.
Postgres is hardly the only daemon for which killing the parent results
in far worse DOS than not doing so. sendmail, sshd, inetd, and mysqld
are examples that come to mind immediately, and I am fairly sure that
it's true for apache as well.

Also, how is killing parent and child less invasive than killing only
the child (which is the one actually eating memory, in these cases)?
The reasoning isn't even self-consistent.

> No matter what you do at this point, you lose.

Well, since the authors of the overcommit logic appear uninterested
in running stable userland services, turning it off is the only way
not to lose.

regards, tom lane