On Tue, Jan 10, 2017 at 8:49 AM, Tsunakawa, Takayuki
<tsunakawa.ta...@jp.fujitsu.com> wrote:
> Hello, Amit, Magnus,
> I'm sorry for my late reply.  Yesterday was a national holiday in Japan.
> From: pgsql-hackers-ow...@postgresql.org
>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila
>> 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.
> OK.  The processing takes place in the following order:
> 1. postmaster calls CreateProcess() to start a child postgres in a suspended 
> state.
> 2. postmaster calls VirtualAlloc(MEM_RESERVE) in 
> pgwin32_ReserveSharedMemoryRegion() to reserve the virtual address space in 
> the child to secure space for the shared memory.  This call just affects the 
> virtual address space and does not allocate physical memory.  So the large 
> page is still irrelevant.

Okay, today again reading VirtualAlloc specs, I could see that
MEM_LARGE_PAGES is not not required to reserve the memory region.  It
is only required during allocation.

> I succeeded by following the same procedure using secpol.msc on Win10, 
> running 64-bit PostgreSQL.  I started PostgreSQL as a Windows service because 
> it's the normal way, with the service account being a regular Windows user 
> account(i.e. not LocalSystem).
> But... I failed to start PostgreSQL by running "pg_ctl start" from a command 
> prompt, receiving the same error message as you.  On the other hand, I could 
> start PostgreSQL on a command prompt with administrative privileges 
> (right-click on "Command prompt" from the Start menu and select "Run as an 
> administrator" in the menu.

Hmm.  It doesn't work even on a command prompt with administrative
privileges. It gives below error:

waiting for server to start....2017-01-17 11:20:13.780 IST [4788] FATAL:  could
not create shared memory segment: error code 1450
2017-01-17 11:20:13.780 IST [4788] DETAIL:  Failed system call was CreateFileMap
ping(size=148897792, name=Global/PostgreSQL:E:/WorkSpace/PostgreSQL/master/Data)
2017-01-17 11:20:13.780 IST [4788] LOG:  database system is shut down
 stopped waiting
pg_ctl: could not start server
Examine the log output.

Now, error code 1450 can occur due to insufficient system resources,
so I have tried by increasing the size of shared memory (higher value
of shared_buffers) without your patch and it works.  This indicates
some problem with the patch.

>  It seems that Windows removes many privileges, including "Lock Pages in 
> Memory", when starting the normal command prompt.  As its evidence, you can 
> use the attached priv.c to see what privileges are assigned and and 
> enabled/disabled.  Build it like "cl priv.c" and just run priv.exe on each 
> command prompt.  Those runs show different privileges.

This is bad.

> Should I need to do something, e.g. explain in the document that the user 
> should use the command prompt with administrative privileges when he uses 
> huge_pages?

I think it is better to document in some way if we decide to go-ahead
with the patch.

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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to