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

From Gurjeet Singh
Subject Re: /proc/self/oom_adj is deprecated in newer Linux kernels
Date
Msg-id CABwTF4WmOg_YjJs9igdeUkRcBmPeGAtX_uCxoYPHueczuK+Zbw@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 11:52 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> andres@anarazel.de (Andres Freund) writes:
>> On 2014-06-10 11:20:28 -0400, Tom Lane wrote:
>>> Maybe I'm mistaken, but I thought once the fork_process code has reset our
>>> process's setting to zero it's not possible to lower it again (without
>>> privileges we'd not have).
>
>> No, doesn't look that way. It's possible to reset it to the value set at
>> process start. So unless we introduce double forks for every backend
>> start it can be reset by ordinary processes.
>
> That's kind of annoying --- I wonder why they went to the trouble of doing
> that?  But anyway, it's probably not worth the cost of double-forking to
> prevent it.  I still say though that this is not a reason to make it as
> easy as change-a-GUC to break the intended behavior.
>
> Robert's idea of having the start script set an environment variable to
> control the OOM adjustment reset seems like it would satisfy my concern.

I'm fine with this solution. Should this be a constant 0, or be
configurable based on env. variable's value?

-- 
Gurjeet Singh http://gurjeet.singh.im/

EDB www.EnterpriseDB.com



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: /proc/self/oom_adj is deprecated in newer Linux kernels
Next
From: Stephen Frost
Date:
Subject: Re: why postgresql define NTUP_PER_BUCKET as 10, not other numbers smaller