Horton
Menu

Re: Improve logging when using Huge Pages

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, sfrost@snowman.net, 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-04-06T02:06:35Z
Lists: pgsql-hackers 
On Tue, Mar 28, 2023 at 09:35:30AM +0900, Michael Paquier wrote:
> The patch needs to provide more details about the unknown state, IMO,
> to make it crystal-clear to the users what are the limitations of this
> GUC, especially regarding the fact that this is useful when "try"-ing
> to allocate huge pages, and that the value can only be consulted after
> the server has been started.

This is still unanswered?  Perhaps at this stage we'd better consider
that for v17 so as we have more time to agree on the user interface?
--
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