Re: [PATCH] Use new oom_score_adj without a new compile-time constant
От | Robert Haas |
---|---|
Тема | Re: [PATCH] Use new oom_score_adj without a new compile-time constant |
Дата | |
Msg-id | CA+TgmobdTS7x0vyB_26O-9d7mmTdXcw=EiKQfbcaxysAc_2Hig@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Use new oom_score_adj without a new compile-time constant (Dan McGee <dan@archlinux.org>) |
Ответы |
Re: [PATCH] Use new oom_score_adj without a new
compile-time constant
|
Список | pgsql-hackers |
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. 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...!). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: