Horton
Menu

Re: Improve logging when using Huge Pages

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, sfrost@snowman.net, alvherre@alvh.no-ip.org, andres@anarazel.de, 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-06-14T00:15:35Z
Lists: pgsql-hackers 
On Tue, Jun 13, 2023 at 02:50:30PM +0900, Michael Paquier wrote:
> +       Assert(strcmp("unknown", GetConfigOption("huge_pages_status", false, false)) != 0);
> 
> Not sure that there is anything to gain with this assertion in
> CreateSharedMemoryAndSemaphores(), because this is pretty much what
> check_GUC_init() looks after?

There was a second thing that bugged me here.  Would it be worth
adding some checks on huge_pages_status to make sure that it is never
reported as unknown when the server is up and running?  I am not sure
what would be the best location for that because there is nothing
specific to huge pages in the tests yet, but authentication/ with
005_sspi.pl and a second one would do the job?
--
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