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?
Passing in a config setting into initdb would still require a rebuild of all controllers.
That could take months to years at best.
Thanks,
David Angel
Internal Use - Confidential
-----Original Message-----
From: Sisson, David <David_Sisson@Dell.com>
Sent: Monday, January 23, 2023 2:12 PM
To: Tom Lane
Cc: Christophe Pettus; Andres Freund; Tomas Vondra; pgsql-bugs@lists.postgresql.org; Sisson, David; Howell, Stephen
Subject: RE: BUG #17757: Not honoring huge_pages setting during initdb causes DB crash in Kubernetes
That makes sense, the PostgreSQL controllers are calling initdb to create the "postgresql.conf" file before they apply
customizationsto it.
To the consumer, it is just yaml to be added to the "postgresql.conf" file.
That makes it much harder to fix and means it is really the controllers at fault.
This probably needs to be explicitly documented when creating a HA cluster or within initdb docs.
https://www.postgresql.org/docs/15/app-initdb.html
Maybe something about how initdb uses sample and what configuration settings must be pre-configured.
Thanks,
David Angel
Internal Use - Confidential
-----Original Message-----
From: Tom Lane <tgl@sss.pgh.pa.us>
Sent: Monday, January 23, 2023 1:56 PM
To: Sisson, David
Cc: Christophe Pettus; Andres Freund; Tomas Vondra; pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17757: Not honoring huge_pages setting during initdb causes DB crash in Kubernetes
[EXTERNAL EMAIL]
"Sisson, David" <David.Sisson@dell.com> writes:
> The default is "huge_pages = try" which is commented out in the "postgresql.conf.sample" file.
> When a consumer like myself turns it off in the standard "postgresql.conf" file, it should not be turned on when
initdbruns.
What "standard postgresql.conf file"? There is no such thing until initdb creates it.
> There is no way to turn it off without altering the sample config file.
Yup, that's exactly why we are having this discussion.
regards, tom lane