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

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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 00:55:01
Message-ID: 127328f2-4e01-e9ec-c9b1-76aef967343f@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 1/22/23 00:30, Tom Lane wrote:
> Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> writes:
>> On 1/20/23 23:48, PG Bug reporting form wrote:
>>> Here is a PR with a possible fix:
>>> https://github.com/postgres/postgres/pull/114/files
>
>> I doubt we want to just go straight to changing the default value for
>> everyone.
>
> Yeah, that proposal is a non-starter. I could see providing an
> initdb option to adjust the value applied during initdb, though.
>
> Ideally, maybe what we want is a generalized switch that could
> replace any variable in the sample config, along the lines of
> the server's "-c foo=bar". I recall having tried to do that and
> having run into quoting hazards, but I did not try very hard.
>

Yeah, I was looking for something like "-c" in initdb, only to realize
there's nothing like that. The main "problem" with adding that is that
we're unlikely to backpatch that (I guess), and thus it does not really
solve the issue for the OP.

I'm not sure we'd be keen to backpatch a change of the default, but
maybe we would ...

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2023-01-22 01:01:08 Re: BUG #17757: Not honoring huge_pages setting during initdb causes DB crash in Kubernetes
Previous Message Andres Freund 2023-01-22 00:27:04 Re: BUG #17757: Not honoring huge_pages setting during initdb causes DB crash in Kubernetes