Re: [HACKERS] 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” - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [HACKERS] 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”
Date
Msg-id CAA4eK1J8sEcdsGLSQn4TWvyV_c=9-Shpq_c7cA2BP8s0NMS_Kg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] 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>)
Responses Re: [HACKERS] Re: [HACKERS] 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”
List pgsql-hackers
On Sat, May 14, 2016 at 7:33 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Tue, Mar 22, 2016 at 12:56 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> >> >> Yes, same random number generation is not the problem. In windows apart
> >> >> from EEXIST error, EACCES also needs to be validated and returned for
> >> >> new random number generation, instead of throwing an error.
> >> >
> >> > Doing the same handling for EACCES doesn't seem to be sane because if
> >> > EACCES
> >> > came for reason other than duplicate dsm name, then we want to report
> >> > the
> >> > error instead of trying to regenerate the name.  I think here fix should
> >> > be
> >> > to append data_dir path as we do for main shared memory.
> >>
> >> Yes, EACCES may be possible other than duplicate dsm name.
> >
> > So as far as I can see there are two ways to resolve this issue, one is to
> > retry generation of dsm name if CreateFileMapping returns EACCES and second
> > is to append data_dir name to dsm name as the same is done for main shared
> > memory, that will avoid the error to occur.  First approach has minor flaw
> > that if CreateFileMapping returns EACCES due to reason other then duplicate
> > dsm name which I am not sure is possible to identify, then we should report
> > error instead try to regenerate the name
> >
> > Robert and or others, can you share your opinion on what is the best way to
> > proceed for this issue.
>
> I think we should retry on EACCES.  Possibly we should do other things
> too, but at least that.  It completely misses the point of retrying on
> EEXIST if we don't retry on other error codes that can also be
> generated when the segment already exists.
>

Sounds sensible, but if we want to that route, shall we have some mechanism such that if retrying it for 10 times (10 is somewhat arbitrary, but we retry 10 times in PGSharedMemoryCreate, so may be there is some consistency) doesn't give us unique name and we are getting EACCES error, then just throw the error instead of more retries.  This is to ensure that if the API is returning EACCES due to reason other than duplicate handle, then we won't retry indefinitely.


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

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Losing memory references - SRF + SPI
Next
From: Michael Paquier
Date:
Subject: Re: 10.0