MIME-Version: 1.0
References: <YTbjyHkTa2xBdzgf@paquier.xyz>
 <578A8F79-FD13-4408-865F-4D31EE5D8123@amazon.com>
 <YTgy8PdP1+9s6NBz@paquier.xyz>
 <4cc5b434-b174-9aae-197b-737db6cac4e3@oss.nttdata.com>
 <C35CB94F-D391-4E52-AB08-A726112FA852@amazon.com>
 <YTmLQtpUSK77mlGT@paquier.xyz>
 <YTmMLtoLEAjMuRSm@paquier.xyz>
 <6AE0285D-0917-4C05-B6AA-4AEDD2FCBA52@amazon.com>
 <CABUevEweO_ZxTQox=QoO8e3rZQm9qFVU+zdoQvazTH9F7HpdEQ@mail.gmail.com>
 <20220314173417.GA1020555@nathanxps13> <Yi/82cqnpKkZsOjI@paquier.xyz>
In-Reply-To: <Yi/82cqnpKkZsOjI@paquier.xyz>
From: Magnus Hagander <magnus@hagander.net>
Date: Tue, 15 Mar 2022 23:02:37 +0100
Message-ID: 
 <CABUevExgoKMNveD5SvFWOYA4MQvPkDmGxY7DkVRASJED4gBYog@mail.gmail.com>
Subject: Re: Estimating HugePages Requirements?
To: Michael Paquier <michael@paquier.xyz>
Cc: Nathan Bossart <nathandbossart@gmail.com>, "Bossart,
 Nathan" <bossartn@amazon.com>,
	Fujii Masao <masao.fujii@oss.nttdata.com>,
 Justin Pryzby <pryzby@telsasoft.com>,
	Andres Freund <andres@anarazel.de>,
 Mark Dilger <mark.dilger@enterprisedb.com>,
	Don Seiler <don@seiler.us>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CABUevExgoKMNveD5SvFWOYA4MQvPkDmGxY7DkVRASJED4gBYog%40mail.gmail.com>
Precedence: bulk

On Tue, Mar 15, 2022 at 3:41 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> 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 :)

Either does work, but yours has more characters :)


> >> (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.

I think we're talking about two different things here.

I think the "avoid extra logging" would be worth seeing if we can
address for 15.

The "able to run on a live cluster" seems a lot bigger and more scary
and not 15 material.


-- 
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/