Re: /proc/self/oom_adj is deprecated in newer Linux kernels - Mailing list pgsql-hackers

From Robert Haas
Subject Re: /proc/self/oom_adj is deprecated in newer Linux kernels
Date
Msg-id CA+TgmoZ2tDAVB5cLPt=UKHaogw+cfq6ZEis1yCTD_gsBWud9SA@mail.gmail.com
Whole thread Raw
In response to Re: /proc/self/oom_adj is deprecated in newer Linux kernels  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: /proc/self/oom_adj is deprecated in newer Linux kernels  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Jun 10, 2014 at 10:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Jun 10, 2014 at 10:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I don't find that this argument holds any water at all.  Anyone who's
>>> developing their own start script can be expected to manage recompiling
>>> Postgres.
>
>> Huh?  Lots of people install PostgreSQL via, say, RPMs, but may still
>> want to change their startup script locally.
>
> 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, 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?

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

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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: NUMA packaging and patch
Next
From: Robert Haas
Date:
Subject: Re: why postgresql define NTUP_PER_BUCKET as 10, not other numbers smaller