Re: BUG #17448: In Windows 10, version 1703 and later, huge_pages doesn't work. - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: BUG #17448: In Windows 10, version 1703 and later, huge_pages doesn't work.
Date
Msg-id YkQMyhsP7xgLDDT/@paquier.xyz
Whole thread Raw
In response to Re: BUG #17448: In Windows 10, version 1703 and later, huge_pages doesn't work.  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: BUG #17448: In Windows 10, version 1703 and later, huge_pages doesn't work.
List pgsql-bugs
On Sun, Mar 27, 2022 at 12:07:57AM +1300, Thomas Munro wrote:
> There are traces of method to the madness:  It's basically YYMM, but
> then after 2004 they switched to H1 and H2 (first/second half of the
> year) instead of MM, perhaps to avoid confusion with YYYY format year.
> Note also that Windows 10 has a 21H2 and Windows 11 has a 21H2.
>
> Some question I have: is FILE_MAP_LARGE PAGES a macro?  We claim to
> support all those ancient zombie OSes like Windows 7, or maybe it's
> even XP for 11, and this has to be back-patched to 11, so we might
> need to make it conditional.  But conditional on what?  For example,
> does something like the attached work (untested)?  What happens if a <
> 1703 kernel sees this flag, does it reject it or ignore it?

I don't have an answer about how much Windows gets angry if we pass
down to MapViewOfFileEx() the flag FILE_MAP_LARGE_PAGES when running
the code on a version of Windows that does not support it.

Anyway, I think that we could just play it safe.  See for example the
attached, where I use PG_FILE_MAP_LARGE_PAGES at compile time to find
if the value is set.  Then, at run-time, I am just relying on
IsWindowsVersionOrGreater() to do the job, something useful when
huge_pages=on as I guess we should fail hard if we did not know about
FILE_MAP_LARGE_PAGES at compile-time, but try to use huge pages at run
time with version >= 10.0.1703.

Perhaps there is a better thing to do?
--
Michael

Attachment

pgsql-bugs by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Logical replication stops dropping used initial-sync replication slots
Next
From: "Lorenz, Christopher"
Date:
Subject: AW: BUG #17393: Delete database after recovery with point-in-time is still missing datafiles