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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Hot Backup with rsync fails at pg_clog if under load
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Large C files