Hi,
Thank you for your comment.
> I was afraid that logging the message like "could not ..." every time when the server starts up would surprise users
unnecessarily.
> Because the message sounds like it reports a server error.
Fujii-san,
I was worried about the same thing as you.
So the attached patch gets the value of the kernel parameter vm.nr_hugepages,
and if it is the default value of zero, the log level is the same as before.
On the other hand, if any value is set, the level is set to LOG.
I hope I can find a better message other than this kind of implementation.
Regards,
Noriyoshi Shinoda
-----Original Message-----
From: Kyotaro Horiguchi [mailto:horikyota.ntt@gmail.com]
Sent: Friday, September 17, 2021 1:15 PM
To: masao.fujii@oss.nttdata.com
Cc: pryzby@telsasoft.com; Shinoda, Noriyoshi (PN Japan FSIP) <noriyoshi.shinoda@hpe.com>; pgsql-hackers@postgresql.org;
rjuju123@gmail.com;tgl@sss.pgh.pa.us
Subject: Re: Improve logging when using Huge Pages
At Fri, 17 Sep 2021 00:13:41 +0900, Fujii Masao <masao.fujii@oss.nttdata.com> wrote in
>
>
> On 2021/09/08 11:17, Kyotaro Horiguchi wrote:
> > I don't dislike the message, but I'm not sure I like the message is
> > too verbose, especially about it has DETAILS. It seems to me
> > something like the following is sufficient, or I'd like see it even
> > more concise.
> > "fall back anonymous shared memory to non-huge pages: required %zu
> > bytes for huge pages"
> > If we emit an error message for other than mmap failure, it would be
> > like the following.
> > "fall back anonymous shared memory to non-huge pages: huge pages not
> > available"
>
> How about simpler message like "disabling huge pages" or "disabling
> huge pages due to lack of huge pages available"?
Honestly, I cannot have conficence on my wording, but "disabling huge pages" souds like somthing that happens on the OS
layer. "did not use/gave up using huge pages for anounymous shared memory" might work well, I'm not sure, though...
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center