Horton
Menu

Re: Improve logging when using Huge Pages

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: 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-01-24T01:33:35Z
Lists: pgsql-hackers 
Hi,

On 2023-01-23 19:21:00 -0600, Justin Pryzby wrote:
> Michael seemed to support this idea and nobody verbalized hatred of it,
> so I implemented it.  In v15, we have shared_memory_size_in_huge_pages,
> so this adds effective_huge_pages.
> 
> Feel free to suggest a better name.

Hm. Should this be a GUC? There's a reason shared_memory_size_in_huge_pages is
one - it's so it's accessible via -C. But here we could make it a function or
whatnot as well.

I'm ok with this being a GUC, it doesn't feel elegant, but I suspect there's
no realistic elegant answer.

Greetings,

Andres Freund

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