Re: Improve logging when using Huge Pages - Mailing list pgsql-hackers

From Justin Pryzby
Subject Re: Improve logging when using Huge Pages
Date
Msg-id 20230124012100.GB13860@telsasoft.com
Whole thread Raw
In response to Re: Improve logging when using Huge Pages  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Improve logging when using Huge Pages  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Wed, Nov 09, 2022 at 02:04:00PM +0900, Michael Paquier wrote:
> On Wed, Nov 09, 2022 at 11:47:57AM +0900, Kyotaro Horiguchi wrote:
> > Honestly I don't come up with other users of the new
> > log-level. Another possible issue is it might be a bit hard for people
> > to connect that level to huge_pages=try, whereas I think we shouldn't
> > put a description about the concrete impact range of that log-level.
> > 
> > I came up with an alternative idea that add a new huge_pages value
> > try_report or try_verbose, which tell postgresql to *always* report
> > the result of huge_pages = try.
> 
> Here is an extra idea for the bucket of ideas: switch the user-visible
> value of huge_pages to 'on' when we are at "try" but success in using
> huge pages, and switch the visible value to "off".  The idea of Justin
> in [1] to use an internal runtime-computed GUC sounds sensible, as well
> (say a boolean effective_huge_pages?).
> 
> [1]: https://www.postgresql.org/message-id/20221106130426.GG16921@telsasoft.com
> --
> Michael

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.

-- 
Justin

Attachment

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Monotonic WindowFunc support for ntile(), percent_rank() and cume_dist()
Next
From: Andres Freund
Date:
Subject: Re: Improve logging when using Huge Pages