Re: Improve logging when using Huge Pages

Justin Pryzby <pryzby@telsasoft.com>

From: Justin Pryzby <pryzby@telsasoft.com>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: "Shinoda, Noriyoshi (PN Japan FSIP)" <noriyoshi.shinoda@hpe.com>, pgsql-hackers@postgresql.org, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, "rjuju123@gmail.com" <rjuju123@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2021-09-07T13:16:53Z
Lists: pgsql-hackers
On Tue, Sep 07, 2021 at 07:12:36PM +0900, Fujii Masao wrote:
> One big concern about the patch is that log message is always reported
> when shared memory fails to be allocated with huge pages enabled
> when huge_pages=try. Since huge_pages=try is the default setting,
> many users would see this new log message whenever they start
> the server. Those who don't need huge pages but just use the default
> setting might think that such log messages would be noisy.

I don't see this as any issue.  We're only talking about a single message on
each restart, which would be added in a major release.  If it's a problem, the
message could be a NOTICE or INFO, and it won't be shown by default.

I think it should say "with/out huge pages" without "enabled/disabled", without
"again", and without "The server", like:

+                                       (errmsg("could not map anonymous shared memory (%zu bytes)"
+                                               " with huge pages.", allocsize),
+                                        errdetail("Anonymous shared memory will be mapped "
+                                               "without huge pages.")));

-- 
Justin



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