Horton
Menu

Re: Improve logging when using Huge Pages

Kyotaro Horiguchi <horikyota.ntt@gmail.com>

View thread
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-03-23T08:25:46Z
Lists: pgsql-hackers 
At Thu, 23 Mar 2023 07:23:28 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
> On Wed, Mar 22, 2023 at 05:18:28PM -0500, Justin Pryzby wrote:
> > Wow, good point.  I think to make it work we'd need put
> > huge_pages_active into BackendParameters and handle it in
> > save_backend_variables().  If so, that'd be strong argument for using a
> > GUC, which already has all the necessary infrastructure for exposing the
> > server's state.
> 
> I am afraid so, duplicating an existing infrastructure for a need like
> the one of this thread is not really appealing.

Wouldn't storing the value in the shared memory itself work? Though,
that space does become almost dead for the server's lifetime...

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