Horton
Menu

Re: Improve logging when using Huge Pages

Nathan Bossart <nathandbossart@gmail.com>

View thread
From: Nathan Bossart <nathandbossart@gmail.com>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Stephen Frost <sfrost@snowman.net>, Alvaro Herrera <alvherre@alvh.no-ip.org>, 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-03-09T19:46:08Z
Lists: pgsql-hackers 
On Thu, Mar 09, 2023 at 10:38:56AM -0600, Justin Pryzby wrote:
> On Thu, Mar 09, 2023 at 09:34:10AM -0500, Stephen Frost wrote:
>> To that end- perhaps this isn't appropriate as a GUC at all?  Why not
>> have this just be a system information function?  Functionally it really
>> provides the same info- if the server is running then you get back
>> either true or false, if it's not then you can't call it but that's
>> hardly different from an unknown or error result.
> 
> We talked about making it a function ~6 weeks ago.
> 
> Is there an agreement to use a function, instead ?

If we're tallying votes, please count me as +1 for a system information
function.  I think that nicely sidesteps having to return "unknown" in some
cases, which I worry will just cause confusion.  IMHO it is much more
obvious that the value refers to the current server if you have to log in
and execute a function to see it.

-- 
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