On Sat, Mar 26, 2022 at 9:24 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
> On Sat, Mar 26, 2022 at 02:46:45PM +0900, Michael Paquier wrote:
> > On Fri, Mar 25, 2022 at 07:52:57AM +0000, PG Bug reporting form wrote:
> > > On this page (*) says that in Windows 10, version 1703 and later OS
> > > versions,
> > > you must specify the FILE_MAP_LARGE_PAGES flag with the MapViewOfFile
> > > function
> > > to map large pages.
> > >
> > > I think it seems to be the cause that MapViewOfFile() in
> > > src/backend/port/win32_shmem.c
> > > does not specify FILE_MAP_LARGE_PAGES flag.
> >
> > I don't have a Windows 10 machine as recent as that at hand, though..
>
> I have a Windows 10 apparently version 20H2 (the versioning doesn't make any
> sense) with all needed to compile postgres at hand. I can have a look next
> week.
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.
Hmm, so all versions of Windows that our current coding worked on were
EOL'd 6 months after PostgreSQL 11 came out with huge_pages support
for Windows:
https://en.wikipedia.org/wiki/Windows_10_version_history
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?
