Re: Supporting huge pages on Windows

On Thu, Jan 5, 2017 at 8:42 AM, Tsunakawa, Takayuki
<tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> wrote:
>> Your version of the patch looks better than the previous one. Don't you
>> need to consider MEM_LARGE_PAGES in VirtualAllocEx call (refer
>> pgwin32_ReserveSharedMemoryRegion)? At least that is what is mentioned
>> in MSDN [1]. Another point worth considering is that currently for
>> VirtualAllocEx() we use PAGE_READWRITE as flProtect value, shouldn't it
>> be same as used in CreateFileMapping() by patch.
>>
>>
>> [1] -
>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa366720(v=vs
>> .85).aspx
>
> No, it's not necessary. Please see PGSharedMemoryReAttach(), where VirtualFree() is called to free the reserved address space and then call MapViewOfFile() to allocate the already created shared memory to that area.
>

PGSharedMemoryReAttach is called after the startup of new process
whereas pgwin32_ReserveSharedMemoryRegion is called before the new
process could actually start. Basically,
pgwin32_ReserveSharedMemoryRegion is used to reserve shared memory for
each backend, so calling VirtualAlloc there should follow spec for
huge pages. If you have some reason for not using, then it is not
clear from your reply, can you try to explain in detail.

I have tried to test v4 version of the patch and it is always failing
in below error after call to AdjustTokenPrivileges:

+ if (GetLastError() != ERROR_SUCCESS)
+ {
+ if (GetLastError() == ERROR_NOT_ALL_ASSIGNED)
+ ereport(elevel,
+ (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
+ errmsg("could not enable Lock pages in memory user right"),
+ errhint("Assign Lock pages in memory user right to the Windows user
account which runs PostgreSQL.")));

I have ensured that user used to run PostgreSQL has "Lock pages in
memory" privilege/rights. I have followed msdn tips [1] to do that
(restarted the m/c after assigning privilege). I am using Win7. Can
you share the steps you have followed to test and your windows m/c
details?

+ if (!LookupPrivilegeValue(NULL, SE_LOCK_MEMORY_NAME, &luid))
+ {
+ CloseHandle(hToken);
+ ereport(elevel,
+ (errmsg("could not enable Lock pages in memory user right: error
code %lu", GetLastError()),
+ errdetail("Failed system call was LookupPrivilegeValue.")));
+ return FALSE;
+ }

The order of closing handle and ereport is different here than other
places in the same function. If there is no specific reason for doing
so, then keep the order consistent.

[1] - https://msdn.microsoft.com/en-us/library/windows/desktop/ff961911(v=vs.85).aspx

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com