From: | Gurjeet Singh <gurjeet(at)singh(dot)im> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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:22:37 |
Message-ID: | CABwTF4Vaj9V47SewP6UJEKBbfZipPBowE1p_NXZQwPsvpS4gXw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 10, 2014 at 10:02 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.
I respectfully disagree. Writing and managing init/start scripts
requires much different set of expertise than compiling and managing
builds of a critical software like a database product.
I would consider adding `echo -1000 > /proc/self/oom_score_adj` to a
start script as a deployment specific tweak, and not 'developing own
start script'.
> 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.
From experiments last night, I see that child process' oom_score_adj
is capped by the parent process' setting that is forking. So I don't
think it's a security risk from that perspective.
I'll retest and provide the exact findings.
Best regards,
--
Gurjeet Singh http://gurjeet.singh.im/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-06-10 14:27:34 | Re: why postgresql define NTUP_PER_BUCKET as 10, not other numbers smaller |
Previous Message | Robert Haas | 2014-06-10 14:21:46 | Re: /proc/self/oom_adj is deprecated in newer Linux kernels |