On Sat, Oct 17, 2015 at 12:07 AM, Robert Haas <robertmh...@gmail.com> wrote: > > On Thu, Oct 15, 2015 at 11:32 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > > 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). > > Maybe we need to be using PostmasterRandom() rather than random() for > the control segment name. >
+1. Though I think it is better to investigate the actual cause before doing this. > But regardless, this patch isn't the right fix. > dsm_impl_op(DSM_OP_CREATE, ...) is supposed to return false in the > event of a segment-already-exists condition, without ereporting. > Thats right, but in this case, it seems from what is reported, that we are hitting Access Denied error which on retry seems to disappear (which ideally shouldn't happen). It's not clear to me why that is happening. By reading code, it appears that previously when we get such errors for main shared memory, we replaced the usage of 'Global\PostreSQL:..' to 'Global/PostgreSQL:.. (refer GetSharedMemName()), but in case of dsm we have already taken care of same, so not sure what else could be reason for Access Denied error. Dmitry, can we try to see what is the exact value of GetLastError() when it fails (one way is to check the logs at DEBUG5 level, _dosmaperr() will print that value or you can modify the code to see it.) Which Windows version you are using? With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
