Re: Improve logging when using Huge Pages

Julien Rouhaud <rjuju123@gmail.com>

From: Julien Rouhaud <rjuju123@gmail.com>
To: "Shinoda, Noriyoshi (PN Japan FSIP)" <noriyoshi.shinoda@hpe.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2021-08-31T06:57:47Z
Lists: 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 success or failure of the HugePages acquisition. If you want to output logs, you need to set log_min_messages=DEBUG3, but it 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 that HugePages 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.



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