Re: /proc/self/oom_adj is deprecated in newer Linux kernels

On Tue, Jun 10, 2014 at 11:14 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Jun 10, 2014 at 10:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> So?  The RPM packager could probably be expected to have compiled with the
>>> oom-adjust-reset option enabled.  If not, why aren't these people lobbying
>>> the packager to meet their expectation?
>
>> Because that might take years to happen,
>
> ... unlike adding a GUC?

/me shrugs.

Sure, it'll take a release cycle, but once we've made this
configurable, it'll always be configurable.  New packagers who don't
have this set up properly can show up at any time.

>> or the packager might never
>> do it at all on the theory that what is good for customers in general
>> is different than what's good for one particular customer, or on the
>> theory that it's just not a high enough priority for that packager.
>
>> Are you seriously saying that you've never needed to customize a
>> startup script on a RHEL box somewhere?
>
> Sure, but what's that have to do with this?  Any Red Hat or PGDG RPM will
> come with this code already enabled in the build, so there is no need for
> anyone to have a GUC to play around with the behavior.

Well, clearly, somebody hasn't got it right, or there wouldn't be this
complaint.  I'll grant you that "somebody" may be EnterpriseDB's own
packaging in this instance, but I wouldn't like to bet that no one
else has ever got this wrong nor ever will.  Peter asked upthread why
this wasn't a GUC with the comment that "Why is this feature not a
run-time configuration variable or at least a configure option?  It's
awfully well hidden now.  I doubt a lot of people are using this even
though they might wish to."  I think that's quite right, and note that
Peter is in no way affiliated with EnterpriseDB and made that comment
(rather presciently) long before Gurjeet's recent report.

>>> I remain of the opinion that allowing nonprivileged people to decide
>>> whether that code is active or not is unsafe from a system level.
>
>> On what factual basis?
>
> Because it would convert the intended behavior (postmaster and only
> postmaster is exempt from OOM kill) into a situation where possibly
> all of the database processes are exempt from OOM kill, at the whim
> of somebody who should not have the privilege to decide that.

Gurjeet already refused that argument.  Apparently, the child
processes can only increase their chance of being OOM-killed, not
decrease it, so you have this exactly backwards: right now, an
individual system administrator can exempt all of the database
processes from OOM kill, but cannot exempt the postmaster alone.

> In my view, the root-owned startup script grants OOM exemption to
> the postmaster because it *knows* that the postmaster's children
> will drop the exemption.  If that trust can be violated because some
> clueless DBA decided to frob a GUC setting, I'd be a lot more hesitant
> about giving the postmaster the exemption in the first place.

How about using an environment variable?  It seems to me that would
address the concern about DBAs without shell access.  They might be
able to frob GUCs, but presumably not the postmaster's starting
environment.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company