Re: Estimating HugePages Requirements? - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Estimating HugePages Requirements?
Date
Msg-id Yi/82cqnpKkZsOjI@paquier.xyz
Whole thread Raw
In response to Re: Estimating HugePages Requirements?  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: Estimating HugePages Requirements?  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
On Mon, Mar 14, 2022 at 10:34:17AM -0700, Nathan Bossart wrote:
> On Mon, Mar 14, 2022 at 04:26:43PM +0100, Magnus Hagander wrote:
>> And in fact, the command documented on
>> https://www.postgresql.org/docs/devel/kernel-resources.html doesn't
>> actually produce the output that the docs show, it also shows the log
>> line, in the default config? If we can't fix the extra logging we
>> should at least have our docs represent reality -- maybe by adding a
>> "2>/dev/null" entry? But it'd be better to have it not output that log
>> in the first place...
>
> I attached a patch to adjust the documentation for now.  This apparently
> crossed my mind earlier [0], but I didn't follow through with it for some
> reason.

Another thing that we can add is -c log_min_messages=fatal, but my
method is more complicated than a simple redirection, of course :)

>> (Of course what I'd really want is to be able to run it on a cluster
>> that's running, but that was discussed downthread so I'm not bringing
>> that one up for changes now)
>
> I think it is worth revisiting the extra logging and the ability to view
> runtime-computed GUCs on a running server.  Should this be an open item for
> v15, or do you think it's alright to leave it for the v16 development
> cycle?

Well, this is a completely new problem as it opens the door of
potential concurrent access issues with the data directory lock file
while reading values from the control file.  And that's not mandatory
to be able to get those estimations without having to allocate a large
chunk of memory, which was the primary goal discussed upthread as far
as I recall.  So I would leave that as an item to potentially tackle
in future versions.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: pg_ls_tmpdir to show directories and shared filesets (and pg_ls_*)
Next
From: Michael Paquier
Date:
Subject: Re: pg_ls_tmpdir to show directories and shared filesets (and pg_ls_*)