On Fri, Sep 23, 2011 at 2:49 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Sep 19, 2011 at 4:36 PM, Dan McGee <dan@archlinux.org> wrote:
>> [ patch ]
>
> I suppose it's Tom who really needs to comment on this, but I'm not
> too enthusiastic about this approach. Duplicating the Linux kernel
> calculation into our code means that we could drift if the formula
> changes again.
Why would the formula ever change? This seems like a different excuse
way of really saying you don't appreciate the hacky approach, which I
can understand completely. However, it simply doesn't make sense for
them to change this formula, as it scales the -17 to 16 old range to
the new -1000 to 1000 range. Those endpoints won't be changing unless
a third method is introduced, in which case this whole thing is mute
and we'd need to fix it yet again.
> I like Tom's previous suggestion (I think) of allowing both constants
> to be defined - if they are, then we try oom_score_adj first and fall
> back to oom_adj if that fails. For bonus points, we could have
> postmaster stat() its own oom_score_adj file before forking and set a
> global variable to indicate the results. That way we'd only ever need
> to test once per postmaster startup (at least until someone figures
> out a way to swap out the running kernel without stopping the
> server...!).
This would be fine, it just seems unreasonably complicated, not to
mention unnecessary. I might as well point this out [1]. I don't think
a soul out there has built without defining this to 0 (if they define
it at all), and not even that many people are using it. Is it all that
bad of an idea to just force it to 0 for both knobs and be done with
it?
-Dan McGee
[1] http://www.google.com/codesearch#search/&q=LINUX_OOM_ADJ=&type=cs
- Slackware and Fedora are the only hits not in the PG codebase, and
both define it to 0.
