Re: Improve logging when using Huge Pages
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.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-03-22T07:37:01Z
Lists: pgsql-hackers
On Tue, Mar 21, 2023 at 09:19:41PM -0500, Justin Pryzby wrote:
> You set this patch to "waiting on author" twice. Would you let me know
> what I could do to help progress the patch? Right now, I have no idea.
My mistake, I've been looking at an incorrect version of the patch.
Thanks for correcting me here.
I have read through the proposed v5 of the patch, that seems to be the
latest one available:
https://www.postgresql.org/message-id/ZA+Bpk/6LcYiUXnh@telsasoft.com
I have noted something.. For the WIN32 case, we have that:
+++ b/src/backend/port/win32_shmem.c
@@ -327,6 +327,8 @@ retry:
Sleep(1000);
continue;
}
+
+ huge_pages_active = ((flProtect & SEC_LARGE_PAGES) != 0);
break;
Are you sure that this is correct? This is set in
PGSharedMemoryCreate(), part of CreateSharedMemoryAndSemaphores() in
the startup sequence that creates the shmem segment. However, for a
normal backend created by EXEC_BACKEND, SubPostmasterMain() reattaches
to an existing shared memory segment, so we don't go through the
creation path that would set huge_pages_active for the process just
started, (note that InitPostmasterChild() switches IsUnderPostmaster,
bypassing the shmem segment creation).
--
Michael
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