pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Justin Pryzby <pryzby@telsasoft.com>
To: John Naylor <john.naylor@enterprisedb.com>
Cc: Thomas Munro <thomas.munro@gmail.com>
Cc: Shinoda, Noriyoshi (PN Japan FSIP) <noriyoshi.shinoda@hpe.com>
Cc: Jacob Champion <jchampion@timescale.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: pgsql-hackers@postgresql.org, Julien Rouhaud <rjuju123@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Subject: Re: Improve logging when using Huge Pages
Date: Sun, 6 Nov 2022 07:04:26 -0600
Message-ID: <20221106130426.GG16921@telsasoft.com> (raw)
In-Reply-To: <CAFBsxsHKsdZjZfXVqxJMpFz4kFq82PsR1pKOEkGzLaeA6ONvnQ@mail.gmail.com>
References: <20211022023815.GI741@telsasoft.com>
	<TU4PR8401MB11529CCEE0FCC07EEE9F8FA7EE859@TU4PR8401MB1152.NAMPRD84.PROD.OUTLOOK.COM>
	<20211028220534.GB31568@telsasoft.com>
	<d928cc86-8e03-b481-18f7-2cb9c28fc724@oss.nttdata.com>
	<CAD21AoDrEma7ZGid2siYMDSa559O3Ox+N_D2B6vGwN5opqYr1w@mail.gmail.com>
	<TU4PR8401MB1152ECB9368A5CCC9AB0835DEE9F9@TU4PR8401MB1152.NAMPRD84.PROD.OUTLOOK.COM>
	<d0a35f68-5d13-306c-f589-0ce816e952a5@timescale.com>
	<DM4PR84MB1734812E1690CD7BEB4B9C57EE9C9@DM4PR84MB1734.NAMPRD84.PROD.OUTLOOK.COM>
	<CA+hUKGJCZaeJX+z-qNnkgMW2B0FiqxfmaT7ALj7GwMRtNjjLog@mail.gmail.com>
	<CAFBsxsHKsdZjZfXVqxJMpFz4kFq82PsR1pKOEkGzLaeA6ONvnQ@mail.gmail.com>

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





view thread (93+ messages)  latest in thread

Message-ID: <20221106130426.GG16921@telsasoft.com>
Permalink:  ../20221106130426.GG16921@telsasoft.com/
Also on:    postgresql.org/message-id/20221106130426.GG16921@telsasoft.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: pryzby@telsasoft.com, john.naylor@enterprisedb.com, thomas.munro@gmail.com, noriyoshi.shinoda@hpe.com, jchampion@timescale.com, sawada.mshk@gmail.com, masao.fujii@oss.nttdata.com, rjuju123@gmail.com, tgl@sss.pgh.pa.us, horikyota.ntt@gmail.com
  Subject: Re: Improve logging when using Huge Pages
  In-Reply-To: <20221106130426.GG16921@telsasoft.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox