Re: /proc/self/oom_adj is deprecated in newer Linux kernels

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: /proc/self/oom_adj is deprecated in newer Linux kernels
Дата
Msg-id CA+TgmoZ2tDAVB5cLPt=UKHaogw+cfq6ZEis1yCTD_gsBWud9SA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: /proc/self/oom_adj is deprecated in newer Linux kernels  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: /proc/self/oom_adj is deprecated in newer Linux kernels
Список pgsql-hackers
On Tue, Jun 10, 2014 at 10:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Jun 10, 2014 at 10:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I don't find that this argument holds any water at all.  Anyone who's
>>> developing their own start script can be expected to manage recompiling
>>> Postgres.
>
>> Huh?  Lots of people install PostgreSQL via, say, RPMs, but may still
>> want to change their startup script locally.
>
> So?  The RPM packager could probably be expected to have compiled with the
> oom-adjust-reset option enabled.  If not, why aren't these people lobbying
> the packager to meet their expectation?

Because that might take years to happen, or the packager might never
do it at all on the theory that what is good for customers in general
is different than what's good for one particular customer, or on the
theory that it's just not a high enough priority for that packager.

Are you seriously saying that you've never needed to customize a
startup script on a RHEL box somewhere?

> I remain of the opinion that allowing nonprivileged people to decide
> whether that code is active or not is unsafe from a system level.

On what factual basis?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: NUMA packaging and patch
Следующее
От: Robert Haas
Дата:
Сообщение: Re: why postgresql define NTUP_PER_BUCKET as 10, not other numbers smaller