Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618”: Permission denied” - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618”: Permission denied”
Date
Msg-id CAA4eK1+pjtDouF-Lc9y0UgFDmWHnaf4KwiM1Y3Anq0wZ1gwsAA@mail.gmail.com
Whole thread Raw
In response to Re: Windows service is not starting sothere’s message in log: FATAL: "could not create sharedmemory segment“Global/PostgreSQL.851401618”: Permissiondenied”  (Dmitry Vasilyev <d.vasilyev@postgrespro.ru>)
Responses Re: Re: [HACKERS] Windows service is not starting sothere’s message in log: FATAL: "could not createshared memory segment “Global/PostgreSQL.851401618”: Permissiondenied”  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Re: Windows service is not starting sothere’s message in log: FATAL: "could not create sharedmemory segment“Global/PostgreSQL.851401618”: Permissiondenied”  (Dmitry Vasilyev <d.vasilyev@postgrespro.ru>)
Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618”: Permission denied”  (Robert Haas <robertmhaas@gmail.com>)
Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618”: Permission denied”  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, Oct 15, 2015 at 8:35 PM, Dmitry Vasilyev <d.vasilyev@postgrespro.ru> wrote:
I think that function dsm_impl_windows() with EACCES error should not
do ereport() with FATAL level. It works, but it is likely to make an
infinite loop if the user will receive EACCES error.


Currently we are using error level as ERROR for creating dsm during
postmaster startup which is not right and rather we should use error
level as LOG.  Can you please try with the attached patch and see
if the issue is fixed for you.

Another some what related point is currently we are using random()
function to ensure a unique name for dsm and it seems to me that
it is always going to generate same number on first invocation (at least
thats what happening on windows) due to which you are seeing the
error.  Another options could be to append current pid or data directory
path as we are doing in win32_shmem.c.  I think this could be an
optimization which can be done in addition to the fix attached (we can
do this as a separate patch as well, if we agreed to do anything).


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

pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Foreign join pushdown vs EvalPlanQual
Next
From: Haribabu Kommi
Date:
Subject: Re: Parallel Seq Scan