Horton
Menu

Re: Improve logging when using Huge Pages

John Naylor <john.naylor@enterprisedb.com>

View thread
From: John Naylor <john.naylor@enterprisedb.com>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: "Shinoda, Noriyoshi (PN Japan FSIP)" <noriyoshi.shinoda@hpe.com>, Jacob Champion <jchampion@timescale.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Fujii Masao <masao.fujii@oss.nttdata.com>, Justin Pryzby <pryzby@telsasoft.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Julien Rouhaud <rjuju123@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Date: 2022-11-06T07:04:29Z
Lists: pgsql-hackers 
On Thu, Nov 3, 2022 at 8:11 AM Thomas Munro <thomas.munro@gmail.com> wrote:
>
> I wonder if the problem here is that people are reluctant to add noise
> to every starting system.   There are people who have not configured
> their system and don't want to see that noise, and then some people
> have configured their system and would like to know about it if it
> doesn't work so they can be aware of that, but don't want to use "off"
> because they don't want a hard failure.  Would it be better if there
> were a new level "try_log" (or something), which only logs a message
> if it tries and fails?

I think the best thing to do is change huge_pages='on' to log a WARNING and
fallback to regular pages if the mapping fails. That way, both dev and prod
can keep the same settings, since 'on' will have both visibility and
robustness. I don't see a good reason to refuse to start -- seems like an
anti-pattern.

--
John Naylor
EDB: http://www.enterprisedb.com

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