Horton
Menu

Re: Improve logging when using Huge Pages

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: sfrost@snowman.net, pryzby@telsasoft.com, 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-20T04:54:46Z
Lists: pgsql-hackers 
On Tue, Mar 14, 2023 at 02:02:19PM +0900, Kyotaro Horiguchi wrote:
> Regarding huge_page_active, its value remains constant throughout a
> postmaster's lifespan. In this regard, GUC may be a better fit for
> this information.  The issue with using GUC for this value is that the
> postgres command cannot report the final value via the -C option,
> which may be the reason for the third alternative "unknown".
> 
> I slightly prefer using a function for this, as if GUC is used, it can
> only return "unknown" for the command "postgres -C
> huge_page_active". However, apart from this advantage, I prefer using
> a GUC for this information.

The main advantage of a read-only GUC over a function is that users
would not need to start a postmaster to know if huge pages would be
active or not.  This is the main reason why a GUC would be a better
fit, in my opinion, because it makes for a cheaper check, while still
allowing a SQL query to check the value of the GUC.
--
Michael

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