Hi Tom,
Thank you for the reply.
What I mean is that during the initialization phase, Postgres will call a command with
system("/usr/lib/postgresql10/bin/postgres"--boot -x0 -F -c max_connections=100 -c shared_buffers=1000 -c
dynamic_shared_memory_type=none< "/dev/null" > "/dev/null" 2>&1").
In this command, the process doesn't read the parameter 'huge_pages', so it will take the default value 'try'.
With 'huge_pages'='try', Postgres will try using huge pages first. But in K8s environment, if the huge pages are
enabledon the worker node but the pod running PG is NOT allocated with huge pages, the testing command(mentioned above,
inthe system() call) will core dump.
That's what the statement 'In a K8s cluster environment, sometimes this will lead to the testing process core dump.'
means.
So we hope that the testing command will read the 'huge_pages' parameter. If the 'huge_pages' in
'postgresql.conf.sample'can be read by the testing command, the parameter can be set to 'off' to avoid the core dump.
Thanks.
BRs
Zhangmin
-----Original Message-----
From: Tom Lane <tgl@sss.pgh.pa.us>
Sent: Monday, December 6, 2021 11:43 PM
To: Min Zhang XX <min.xx.zhang@ericsson.com>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17323: test_config_settings during postgres initialization does not read the parameter huge_pages
PG Bug reporting form <noreply@postgresql.org> writes:
> In the function test_config_settings() which will run during postgres
> initialization, the logic will create a new process to test what
> default parameters(such as max_connections, shared_buffers) can be set.
> However, it seems the new process so called testing process does not
> take the parameter huge_pages(in postgresql.conf.sample) into account.
The initial configuration will never have huge_pages enabled.
If you want that, it's up to you to adjust the settings afterwards --- and that typically would also involve changing
shared_buffers. (The settings that initdb would choose are not large enough to justify worrying about huge pages
anyway.)
> In a K8s cluster environment, sometimes this will lead to the testing
> process core dump.
This claim is quite detail-free, so I don't see how we are supposed to respond to it.
regards, tom lane