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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Jun 10, 2014 at 10:51 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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?

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

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

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.

regards, tom lane