Re: Improve logging when using Huge Pages
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Andres Freund <andres@anarazel.de>, 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-02-09T19:29:09Z
Lists: pgsql-hackers
On Thu, Feb 09, 2023 at 10:40:13AM +0100, Alvaro Herrera wrote: > On 2023-Feb-08, Justin Pryzby wrote: >> I don't think it makes sense to run postgres -C huge_pages_active, >> however, so I see no issue that that would always returns "false". > > Hmm, I would initialize it to return "unknown" rather than "off" — and > make sure it turns "off" at the appropriate time. Otherwise you're just > moving the confusion elsewhere. I think this approach would address my concerns about using a GUC. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
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