On Fri, Sep 23, 2011 at 4:05 PM, Dan McGee <d...@archlinux.org> wrote: > On Fri, Sep 23, 2011 at 2:49 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Mon, Sep 19, 2011 at 4:36 PM, Dan McGee <d...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
