On Wed, Sep 01, 2021 at 06:28:21PM +0000, Bossart, Nathan wrote:
> On 8/31/21, 11:54 PM, "Michael Paquier" <michael@paquier.xyz> wrote:
>> Hmm. I am not sure about the addition of huge_pages_required, knowing
>> that we would have shared_memory_size. I'd rather let the calculation
>> part to the user with a scan of /proc/meminfo.
>
> I included this based on some feedback from Andres upthread [0]. I
> went ahead and split the patch set into 3 pieces in case we end up
> leaving it out.
Thanks. Anyway, we don't really need huge_pages_required on Windows,
do we? The following docs of Windows tell what do to when using large
pages:
https://docs.microsoft.com/en-us/windows/win32/memory/large-page-support
The backend code does that as in PGSharedMemoryCreate(), now that I
look at it. And there is no way to change the minimum large page size
there as far as I can see because that's decided by the processor, no?
There is a case for shared_memory_size on Windows to be able to adjust
the sizing of the memory of the host, though.
>> +#elif defined(WIN32)
>> + hp_size = GetLargePageMinimum();
>> +#endif
>> +
>> +#if defined(MAP_HUGETLB) || defined(WIN32)
>> + hp_required = (size_b / hp_size) + 1;
>> As of [1], there is the following description:
>> "If the processor does not support large pages, the return value is
>> zero."
>> So there is a problem here.
>
> I've fixed this in v4.
At the end it would be nice to not finish with two GUCs. Both depend
on the reordering of the actions done by the postmaster, so I'd be
curious to hear the thoughts of others on this particular point.
--
Michael
