Re: Improve logging when using Huge Pages
Justin Pryzby <pryzby@telsasoft.com>
From: Justin Pryzby <pryzby@telsasoft.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, thomas.munro@gmail.com, tgl@sss.pgh.pa.us, andres@anarazel.de, 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:21:00Z
Lists: pgsql-hackers
Attachments
- 0001-add-GUC-effective_huge_pages.patch (text/x-diff)
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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add GUC parameter "huge_pages_status"
- a14354cac0e3 17.0 landed
-
Add check on initial and boot values when loading GUCs
- a73952b79563 16.0 cited
-
Clean up some inconsistencies with GUC declarations
- d9d873bac670 16.0 cited
-
Clean up some GUC declarations and comments
- 7d25958453a6 16.0 cited