Re: Improve logging when using Huge Pages

Kyotaro Horiguchi <horikyota.ntt@gmail.com>

From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: masao.fujii@oss.nttdata.com
Cc: pryzby@telsasoft.com, noriyoshi.shinoda@hpe.com, pgsql-hackers@postgresql.org, rjuju123@gmail.com, tgl@sss.pgh.pa.us
Date: 2021-09-17T04:14:30Z
Lists: pgsql-hackers
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



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Add GUC parameter "huge_pages_status"

  2. Add check on initial and boot values when loading GUCs

  3. Clean up some inconsistencies with GUC declarations

  4. Clean up some GUC declarations and comments