Re: Improve logging when using Huge Pages - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Improve logging when using Huge Pages
Date
Msg-id CAOBaU_YGfFyruW4YX6++DifTtBt8bjatz0gMhaTRD=dqV3gdWg@mail.gmail.com
Whole thread Raw
In response to Improve logging when using Huge Pages  ("Shinoda, Noriyoshi (PN Japan FSIP)" <noriyoshi.shinoda@hpe.com>)
Responses Re: Improve logging when using Huge Pages  (Fujii Masao <masao.fujii@oss.nttdata.com>)
List pgsql-hackers
On Tue, Aug 31, 2021 at 1:37 PM Shinoda, Noriyoshi (PN Japan FSIP)
<noriyoshi.shinoda@hpe.com> wrote:
>
> In the current version, when GUC huge_pages=try, which is the default setting, no log is output regardless of the
successor failure of the HugePages acquisition. If you want to output logs, you need to set log_min_messages=DEBUG3,
butit will output a huge amount of extra logs. 
> With huge_pages=try setting, if the kernel parameter vm.nr_hugepages is not enough, the administrator will not notice
thatHugePages is not being used. 
> I think it should output a log if HugePages was not available.

I agree that the message should be promoted to a higher level.  But I
think we should also make that information available at the SQL level,
as the log files may be truncated / rotated before you need the info,
and it can be troublesome to find the information at the OS level, if
you're lucky enough to have OS access.



pgsql-hackers by date:

Previous
From: "Bossart, Nathan"
Date:
Subject: Re: .ready and .done files considered harmful
Next
From: Yugo NAGATA
Date:
Subject: Re: Fix around conn_duration in pgbench