On Tue, Jun 12, 2012 at 12:37 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> I was reminded today that we still haven't done anything about this:
>
> Tom Lane <t...@sss.pgh.pa.us> writes:
>> While testing 9.1 RPMs on Fedora 15 (2.6.40 kernel), I notice
>> messages like these in the kernel log:
>> Sep 11 13:38:56 rhl kernel: [  415.308092] postgres (18040): 
>> /proc/18040/oom_adj is deprecated, please use /proc/18040/oom_score_adj 
>> instead.
>
> At this point there are no shipping Fedora versions that don't emit this
> gripe, and F15 is even about to go EOL.
>
> The previous discussion thread at
> http://archives.postgresql.org/pgsql-hackers/2011-09/msg00794.php
> went off into the weeds of what was in my opinion over-design.
> I still think it's sufficient to do what I suggested initially:
>
>> ... The simplest, least risky change that I can think of is to
>> copy-and-paste the relevant #ifdef code block in fork_process.c.
>> If we do that, then it would be up to the packager whether to #define
>> LINUX_OOM_ADJ or LINUX_OOM_SCORE_ADJ or both depending on the behavior
>> he wants.
>
> and would like to squeeze that into 9.2 so that we're only a year late
> and not two years late in responding to this issue :-(.
>
> Objections?

I think my position, and the position of the people who responded to
the original thread, was that it seems like you're architecting a
kludge when it wouldn't be that hard to architect a nicer solution.
That having been said, I don't think it's such a large kludge that we
should all have massive dry heaves at the thought of it living in our
repository.  And then too, this isn't the time to be architecting new
9.2 feature anyway.  So I say go for it.  If it makes your life
easier, back-patch it.  Code that requires a #define to enable it
won't break anything for anyone else.

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to