Re: Improve logging when using Huge Pages

Alvaro Herrera <alvherre@alvh.no-ip.org>

From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Andres Freund <andres@anarazel.de>, Michael Paquier <michael@paquier.xyz>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, thomas.munro@gmail.com, tgl@sss.pgh.pa.us, john.naylor@enterprisedb.com, noriyoshi.shinoda@hpe.com, jchampion@timescale.com, sawada.mshk@gmail.com, masao.fujii@oss.nttdata.com, pgsql-hackers@postgresql.org, rjuju123@gmail.com
Date: 2023-02-02T15:53:37Z
Lists: pgsql-hackers
On 2023-Jan-24, Justin Pryzby wrote:

> On Mon, Jan 23, 2023 at 05:33:35PM -0800, Andres Freund wrote:

> > I'm ok with this being a GUC, it doesn't feel elegant, but I suspect there's
> > no realistic elegant answer.

> Whether it's a GUC or a function, I propose to name it hugepages_active.
> If there's no objections, I'll add to the CF.

Maybe I misread the code (actually I only read the patch), but -- does
it set active=true when huge_pages=on?  I think the code only works when
huge_pages=try.  That might be pretty confusing; I think it should say
"on" in both cases.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"Hay dos momentos en la vida de un hombre en los que no debería
especular: cuando puede permitírselo y cuando no puede" (Mark Twain)



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