On Fri, Sep 23, 2011 at 4:05 PM, Dan McGee <dan@archlinux.org> wrote:
> 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?
Did we do anything about this? Anyone else have an opinion on what
ought to be done?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company