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

From Justin Pryzby
Subject Re: Improve logging when using Huge Pages
Date
Msg-id 20221106130426.GG16921@telsasoft.com
Whole thread Raw
In response to Re: Improve logging when using Huge Pages  (John Naylor <john.naylor@enterprisedb.com>)
List pgsql-hackers
On Sun, Nov 06, 2022 at 02:04:29PM +0700, John Naylor wrote:
> 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.

I'm glad to see there's still discussion on this topic :)

Another idea is to add a RUNTIME_COMPUTED GUC to *display* the state of
huge pages, so I can stop parsing /proc/maps to find it.

-- 
Justin



pgsql-hackers by date:

Previous
From: Ian Lawrence Barwick
Date:
Subject: Re: [patch] Have psql's \d+ indicate foreign partitions
Next
From: Álvaro Herrera
Date:
Subject: Re: Small TAP improvements