From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, david_sisson(at)dell(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17757: Not honoring huge_pages setting during initdb causes DB crash in Kubernetes |
Date: | 2023-01-22 02:08:26 |
Message-ID: | 20230122020826.x6geac6qjiinr66a@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | MRO Mexico Industrial Supplies SA de CV | 2023-01-23 11:10:23 | Request for Quote ITBMRFQ23152 - Product Profiles_936878290323 |
Previous Message | Tom Lane | 2023-01-22 01:01:08 | Re: BUG #17757: Not honoring huge_pages setting during initdb causes DB crash in Kubernetes |