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

On Tue, Jun 10, 2014 at 10:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Gurjeet Singh <gurjeet@singh.im> writes:
>> Startup scripts are not solely in the domain of packagers. End users
>> can also be expected to develop/edit their own startup scripts.
>
>> Providing it as GUC would have given end users both the peices, but
>> with a compile-time option they have only one half of the solution;
>> except if they go compile their own binaries, which forces them into
>> being packagers.
>
> 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.  I don't think those
users should have to give up the benefits of RPM packaging because
they want a different oom_adj value.  Then they have to be responsible
for updating the packages every time there's a new minor release,
instead of just typing 'yum update'.  That's a LOT of extra work.

> Extra GUCs do not have zero cost, especially not ones that are as
> complicated-to-explain as this would be.

NOT having them isn't free either.

> I would also argue that there's a security issue with making it a GUC.
> A non-root DBA should not have the authority to decide whether or not
> postmaster child processes run with nonzero OOM adjustment; that decision
> properly belongs to whoever has authorized the root-owned startup script
> to change the adjustment in the first place.  So seeing this as two
> independent pieces is not only wrong but dangerous.

I think the only possible issue is if the DBA doesn't even have shell
access.  If he doesn't have root but does have shell access, he could
have recompiled anyway - it's just more work.

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