Re: BUG #17757: Not honoring huge_pages setting during initdb causes DB crash in Kubernetes
От | Tomas Vondra |
---|---|
Тема | Re: BUG #17757: Not honoring huge_pages setting during initdb causes DB crash in Kubernetes |
Дата | |
Msg-id | 127328f2-4e01-e9ec-c9b1-76aef967343f@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: BUG #17757: Not honoring huge_pages setting during initdb causes DB crash in Kubernetes (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #17757: Not honoring huge_pages setting during initdb causes DB crash in Kubernetes
Re: BUG #17757: Not honoring huge_pages setting during initdb causes DB crash in Kubernetes |
Список | pgsql-bugs |
On 1/22/23 00:30, Tom Lane wrote: > Tomas Vondra <tomas.vondra@enterprisedb.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
В списке pgsql-bugs по дате отправления: