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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gurjeet Singh <gurjeet(at)singh(dot)im>
Cc: 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 14:02:28
Message-ID: 28946.1402408948@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gurjeet Singh <gurjeet(at)singh(dot)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.

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

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-06-10 14:02:34 Re: "cancelling statement due to user request error" occurs but the transaction has committed.
Previous Message Robert Haas 2014-06-10 14:00:05 Re: [bug fix] Memory leak in dblink