| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | "Sisson, David" <David(dot)Sisson(at)dell(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Christophe Pettus <xof(at)thebuild(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>, "Howell, Stephen" <Stephen(dot)Howell(at)dell(dot)com> |
| Subject: | Re: BUG #17757: Not honoring huge_pages setting during initdb causes DB crash in Kubernetes |
| Date: | 2023-01-23 21:10:13 |
| Message-ID: | 20230123211013.uebdheyxgfakxuiv@awork3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Hi,
On 2023-01-23 20:35:17 +0000, Sisson, David wrote:
> A quick and dirty solution could be to alter initdb to catch the exception and retry using a copy of the sample with "huge_pages=false".
> Would that be acceptable?
This is a kubernetes or postgres-operator bug (setting up the wrong cgroup
limit, which the docs explicitly warn against doing). I don't think we want to
accumulate workarounds like that in postgres.
> Passing in a config setting into initdb would still require a rebuild of all controllers.
> That could take months to years at best.
Huh. I don't know anything about the controller, but that seems problematic
independent of this specific issue. And you'd still need to deploy a new
version of postgres to get such changes...
> Internal Use - Confidential
Hardly.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sisson, David | 2023-01-23 21:41:15 | RE: BUG #17757: Not honoring huge_pages setting during initdb causes DB crash in Kubernetes |
| Previous Message | Sisson, David | 2023-01-23 20:35:17 | RE: BUG #17757: Not honoring huge_pages setting during initdb causes DB crash in Kubernetes |