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