Horton
Menu

Re: Improve logging when using Huge Pages

Nathan Bossart <nathandbossart@gmail.com>

View thread
From: Nathan Bossart <nathandbossart@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Justin Pryzby <pryzby@telsasoft.com>, 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-08T22:56:34Z
Lists: pgsql-hackers 
On Thu, Feb 02, 2023 at 04:53:37PM +0100, Alvaro Herrera wrote:
> 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.

+1

Also, while this is indeed a runtime-computed parameter, it won't be
initialized until after 'postgres -C' has been handled, so 'postgres -C'
will always report it as "off".  However, I'm not sure it makes sense to
check it with 'postgres -C' anyway since you want to know if the current
server is using huge pages.

At the moment, I think I'd vote for a new function instead of a GUC.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

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