Horton
Menu

Re: Improve logging when using Huge Pages

Fujii Masao <masao.fujii@oss.nttdata.com>

View thread
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, pryzby@telsasoft.com
Cc: noriyoshi.shinoda@hpe.com, pgsql-hackers@postgresql.org, rjuju123@gmail.com, tgl@sss.pgh.pa.us
Date: 2021-09-16T15:13:41Z
Lists: pgsql-hackers 

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"?

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

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