On 1/20/23 23:48, PG Bug reporting form wrote:
> The following bug has been logged on the website:
>
> Bug reference: 17757
> Logged by: David Angel
> Email address: david_sisson@dell.com
> PostgreSQL version: 14.5
> Operating system: Linux
> Description:
>
> On an OS where hugepages are enabled, if no hugepages resources are assigned
> in Kubernetes and the postgres instance is set to hugepages = off in the
> config then one would assume that the DB would not use hugepages.
There's no config at that point - it's initdb that creates it, by
copying the .sample file, IIRC. So not sure which file you're modifying.
> However, because the initdb process uses postgresql.conf.sample or
> postgresql.conf.template instead of the actual specified configuration the
> applied setting is actually hugepages = try during initdb.
Specified how?
> In these cases, the initdb phase will attempt to allocate huge pages that
> are available in the OS, but it will be denied access by Kubernetes and
> fail.
Well, so how exactly this fails? Does that mean Kubernetes broke mmap()
with MAP_HUGETLB so that it doesn't return MAP_FAILED when hugepages are
not available, or what? Because that's the only explanation I can see,
looking at the code.
Or it just does not realize there are no hugepages, returns something
and then crashes with SIGBUS later when trying to access it?
>
> 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. IMHO if the "try" logic is somehow broken, we should fix the
try logic, not mess with the defaults.
In the worst case, the operator can probably tweak the .sample config
before calling initdb.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company