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: Gurjeet Singh <gurjeet(at)singh(dot)im>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: /proc/self/oom_adj is deprecated in newer Linux kernels
Date: 2014-06-10 15:51:26
Message-ID: CA+TgmoZHh-0bGQvWOvudgk+7i4wP+bdbf9656YaKVP9TiasngA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 10, 2014 at 11:46 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I'd be okay with a configure option, if you think that would make this
> issue more visible to packagers. It's delegating the responsibility to
> the DBA level that I'm unhappy about.
>
[...]
>
>> How about using an environment variable? It seems to me that would
>> address the concern about DBAs without shell access. They might be
>> able to frob GUCs, but presumably not the postmaster's starting
>> environment.
>
> Hmmm ... yeah, that might work. It would solve the problem I'm worried
> about, which is making sure that the startup script has control of what
> happens.

A configure option wouldn't address the issue from my perspective; you
still have to recompile if you don't like what your packager did, and
your packager might still be stupid. However, an environment variable
seems like it would be just fine. It might even be more convenient
for packagers that having to compile the desired value into the
binary.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-06-10 15:52:17 Re: /proc/self/oom_adj is deprecated in newer Linux kernels
Previous Message Andres Freund 2014-06-10 15:49:32 Re: /proc/self/oom_adj is deprecated in newer Linux kernels