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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: /proc/self/oom_adj is deprecated in newer Linux kernels
Date: 2012-06-12 18:35:39
Message-ID: CA+TgmoY=5O2Z3UhEYbNcyjzq=ZGLNekESZoKNtPT320WV=doyw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 12, 2012 at 1:05 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Jun 12, 2012 at 12:37 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Lonni J Friedman 2012-06-12 18:37:42 Re: pg_basebackup blocking all queries with horrible performance
Previous Message Robert Haas 2012-06-12 18:06:49 Re: 9.3: load path to mitigate load penalty for checksums