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 11:56:01 |
Message-ID: | CABwTF4XDdYiBQXqj=CKrFXN7x2NiBbVnpHSJG6AVnMBLnLBmLA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Sep 19, 2011 at 10:18 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> On sön, 2011-09-18 at 12:21 -0400, Tom Lane wrote:
>>> But having said that, it wouldn't be very hard to arrange things so that
>>> if you did have both symbols defined, the code would only attempt to
>>> write oom_adj if it had failed to write oom_score_adj; which is about as
>>> close as you're likely to get to a kernel version test for this.
>
>> Why is this feature not a run-time configuration variable or at least a
>> configure option? It's awfully well hidden now. I doubt a lot of
>> people are using this even though they might wish to.
>
> See the thread in which the feature was designed originally:
> http://archives.postgresql.org/pgsql-hackers/2010-01/msg00170.php
>
> The key point is that to get useful behavior, you need cooperation
> between both a root-privileged startup script and the PG executable.
> That tends to throw the problem into the domain of packagers, more
> than end users, and definitely puts a big crimp in the idea that
> run-time configuration of just half of the behavior could be helpful.
> So far, no Linux packagers have complained that the design is inadequate
> (a position that I also hold when wearing my red fedora) so I do not
> feel a need to complicate it further.
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 am not alone in feeling that if Postgres wishes to provide a control
over child backend's oom_score_adj, it should be a GUC parameter
rather than a compile-time option. Yesterday a customer wanted to
leverage this and couldn't because they refuse to maintain their own
fork of Postgres code.
Please find attached a patch to turn it into a GUC, #ifdef'd by __linux__ macro.
Best regards,
--
Gurjeet Singh http://gurjeet.singh.im/
Attachment | Content-Type | Size |
---|---|---|
oom_guc.patch | text/x-diff | 2.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-06-10 12:17:10 | Re: Re: why postgresql define NTUP_PER_BUCKET as 10, not other numbers smaller |
Previous Message | Hannu Krosing | 2014-06-10 10:18:28 | Re: "RETURNING PRIMARY KEY" syntax extension |