Re: Improve logging when using Huge Pages

Kyotaro Horiguchi <horikyota.ntt@gmail.com>

From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: michael@paquier.xyz
Cc: pryzby@telsasoft.com, sfrost@snowman.net, alvherre@alvh.no-ip.org, andres@anarazel.de, nathandbossart@gmail.com, jchampion@timescale.com, john.naylor@enterprisedb.com, masao.fujii@oss.nttdata.com, noriyoshi.shinoda@hpe.com, pgsql-hackers@postgresql.org, rjuju123@gmail.com, sawada.mshk@gmail.com, tgl@sss.pgh.pa.us, thomas.munro@gmail.com
Date: 2023-04-11T07:41:18Z
Lists: pgsql-hackers
At Tue, 11 Apr 2023 15:17:46 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
> On Thu, Mar 23, 2023 at 05:25:46PM +0900, Kyotaro Horiguchi wrote:
> > Wouldn't storing the value in the shared memory itself work? Though,
> > that space does become almost dead for the server's lifetime...
> 
> Sure, it would work.  However, we'd still need an interface for the
> extra function.  At this point, a GUC with an unknown state is kind of
> OK for me.  Anyway, where would you stick this state?

(Digging memory..)

Sorry for confusion but I didn't mean to stick to the function.  Just
I thought that some people seem to dislike having the third state for
the should-be-boolean variable.

So, I'm okay with GUC, having "unknown".

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



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