Re: Improve logging when using Huge Pages
Kyotaro Horiguchi <horikyota.ntt@gmail.com>
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: michael@paquier.xyz
Cc: pryzby@telsasoft.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-11T07:41:18Z
Lists: pgsql-hackers
At Tue, 11 Apr 2023 15:17:46 +0900, Michael Paquier <michael@paquier.xyz> wrote in > On Thu, Mar 23, 2023 at 05:25:46PM +0900, Kyotaro Horiguchi wrote: > > Wouldn't storing the value in the shared memory itself work? Though, > > that space does become almost dead for the server's lifetime... > > Sure, it would work. However, we'd still need an interface for the > extra function. At this point, a GUC with an unknown state is kind of > OK for me. Anyway, where would you stick this state? (Digging memory..) Sorry for confusion but I didn't mean to stick to the function. Just I thought that some people seem to dislike having the third state for the should-be-boolean variable. So, I'm okay with GUC, having "unknown". regards. -- Kyotaro Horiguchi NTT Open Source Software Center
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