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

From Michael Paquier
Subject Re: BUG #17448: In Windows 10, version 1703 and later, huge_pages doesn't work.
Date
Msg-id Ymj7GHBfTnaN5kWW@paquier.xyz
Whole thread Raw
In response to Re: BUG #17448: In Windows 10, version 1703 and later, huge_pages doesn't work.  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: BUG #17448: In Windows 10, version 1703 and later, huge_pages doesn't work.  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-hackers
On Tue, Apr 26, 2022 at 12:54:35PM +0800, Julien Rouhaud wrote:
> I searched a bit and apparently some people are using this function directly
> opening some dll, which seems wrong.

I was wondering about this whole business, and the manifest approach
is a *horrible* design for an API where the goal is to know if your
run-time environment is greater than a given threshold.

>> Another Idea on windows machines would be to use the commandline to execute
>> ver in a separate Process and store the result in a file.
>
> That also seems hackish, I don't think that we want to rely on something like
> that.

Hmm.  That depends on the dependency set, I guess.  We do that on
Linux at some extent to for large pages in sysv_shmem.c.  Perhaps this
could work for Win10 if this avoids the extra loopholes with the
manifests.

> Their API is entirely useless,

This I agree.

> so I'm still on the opinion that we should
> unconditionally use the FILE_MAP_LARGE_PAGES flag if it's defined and call it a
> day.

Are we sure that this is not going to cause failures in environments
where the flag is not supported?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Fix NULL pointer reference in _outPathTarget()
Next
From: Bharath Rupireddy
Date:
Subject: Re: pgsql: Add contrib/pg_walinspect.