Re: Improve logging when using Huge Pages

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: michael(at)paquier(dot)xyz
Cc: pryzby(at)telsasoft(dot)com, sfrost(at)snowman(dot)net, alvherre(at)alvh(dot)no-ip(dot)org, andres(at)anarazel(dot)de, nathandbossart(at)gmail(dot)com, jchampion(at)timescale(dot)com, john(dot)naylor(at)enterprisedb(dot)com, masao(dot)fujii(at)oss(dot)nttdata(dot)com, noriyoshi(dot)shinoda(at)hpe(dot)com, pgsql-hackers(at)postgresql(dot)org, rjuju123(at)gmail(dot)com, sawada(dot)mshk(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, thomas(dot)munro(at)gmail(dot)com
Subject: Re: Improve logging when using Huge Pages
Date: 2023-03-23 08:25:46
Message-ID: 20230323.172546.1916979127198972068.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Thu, 23 Mar 2023 07:23:28 +0900, Michael Paquier <michael(at)paquier(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Drouvot, Bertrand 2023-03-23 08:33:16 Re: [BUG] pg_stat_statements and extended query protocol
Previous Message Michael Paquier 2023-03-23 08:24:22 Re: Remove nonmeaningful prefixes in PgStat_* fields