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 ZBt+tCS/Akj8BvHi@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  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Wed, Mar 22, 2023 at 04:37:01PM +0900, Michael Paquier wrote:
> 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).

Wow, good point.  I think to make it work we'd need put
huge_pages_active into BackendParameters and handle it in
save_backend_variables().  If so, that'd be strong argument for using a
GUC, which already has all the necessary infrastructure for exposing the
server's state.

-- 
Justin



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: HOT chain validation in verify_heapam()
Next
From: Michael Paquier
Date:
Subject: Re: Improve logging when using Huge Pages