On Sat, May 14, 2016 at 7:33 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Tue, Mar 22, 2016 at 12:56 AM, Amit Kapila <amit.kapil...@gmail.com>
> >> >> Yes, same random number generation is not the problem. In windows
> >> >> from EEXIST error, EACCES also needs to be validated and returned
> >> >> 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
> >> > 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
> > retry generation of dsm name if CreateFileMapping returns EACCES and
> > is to append data_dir name to dsm name as the same is done for main
> > memory, that will avoid the error to occur.  First approach has minor
> > that if CreateFileMapping returns EACCES due to reason other then
> > dsm name which I am not sure is possible to identify, then we should
> > 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

Reply via email to