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+TgmoY=5O2Z3UhEYbNcyjzq=ZGLNekESZoKNtPT320WV=doyw@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>)
List pgsql-hackers
On Tue, Jun 12, 2012 at 1:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Jun 12, 2012 at 12:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I still think it's sufficient to do what I suggested initially:
>>>> ... The simplest, least risky change that I can think of is to
>>>> copy-and-paste the relevant #ifdef code block in fork_process.c.
>
>> I think my position, and the position of the people who responded to
>> the original thread, was that it seems like you're architecting a
>> kludge when it wouldn't be that hard to architect a nicer solution.
>
> I'd be the first to agree it's a kluge.  But the end result of the
> previous discussion was that it wasn't so obvious how to architect
> a nicer solution.  Nor is there all that much room for people to use a
> nicer solution, given that we need help from not just fork_process.c
> but the root-privileged startup script (or lately in Fedora it's a
> systemd unit script doing the privilege-increasing end of this).

Well, I don't think a GUC or two would be such a bad way of doing it, but...

> In the short run, if we don't have consensus on this, I'll probably
> just carry a Fedora patch like so:
>
> -            int        fd = open("/proc/self/oom_adj", O_WRONLY, 0);
> +            int        fd = open("/proc/self/oom_score_adj", O_WRONLY, 0);
>
> But it seems a tad silly to be carrying such a patch for a block of
> code that is only of interest to Linux packagers anyway, and nearly
> all such packagers are facing this same issue either now or in the
> very near future.

...I also agree with this.

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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: 9.3: load path to mitigate load penalty for checksums
Next
From: Robert Haas
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3