Re: BUG #17757: Not honoring huge_pages setting during initdb causes DB crash in Kubernetes

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: BUG #17757: Not honoring huge_pages setting during initdb causes DB crash in Kubernetes
Дата
Msg-id 20230122020826.x6geac6qjiinr66a@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: BUG #17757: Not honoring huge_pages setting during initdb causes DB crash in Kubernetes  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Ответы RE: BUG #17757: Not honoring huge_pages setting during initdb causes DB crash in Kubernetes
Список pgsql-bugs
Hi,

On 2023-01-22 01:55:01 +0100, Tomas Vondra wrote:
> I'm not sure we'd be keen to backpatch a change of the default, but
> maybe we would ...

After figuring out that it's clearly a configuration issue *somewhere* outside
of postgres's remit, I'm not that sure it's worth doing something concretely
to avoid the SIGBUS issue.


But if we end up doing something, I think a parameter triggering use of
MAP_POPULATE would be a good idea. It's actually useful outside of the SIGBUS
issue, because benchmarks reach a steady state noticably more quickly when
using it.

OTOH, in a production scenario with large shared_buffers I'd probably not want
to use it, because getting up more quickly and and distributing the memory
initialization across across cores is more important.


I think it'd be ok to explicitly specify such an option in initdb - after all,
initdb does do work to determine the correct shared buffers size etc, and
MAP_POPULATE will lead to a more reliable determination.  Not just with huge
pages, but also with "small" pages and system-level memory overcommit.

Greetings,

Andres Freund



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #17757: Not honoring huge_pages setting during initdb causes DB crash in Kubernetes
Следующее
От: "Sisson, David"
Дата:
Сообщение: RE: BUG #17757: Not honoring huge_pages setting during initdb causes DB crash in Kubernetes