On Mon, Oct 12, 2015 at 3:45 PM, Michael Paquier <
michael.paquier@gmail.com> wrote:
>
> On Mon, Oct 12, 2015 at 2:55 PM, Amit Kapila <
amit.kapila16@gmail.com> wrote:
> > On Sun, Oct 11, 2015 at 9:12 PM, Tom Lane <
tgl@sss.pgh.pa.us> wrote:
> > I could easily reproduce the issue if logging collector is on and even if
> > we try to increase the loop count or sleep time in PGSharedMemoryCreate(),
> > it doesn't change the situation as the syslogger has a valid handle to
> > shared memory. One way to fix is to just close the shared memory handle
> > in sys logger as we are not going to need it and attached patch which does
> > this fixes the issue for me. Another invasive fix in case we want to
> > retain shared memory handle for some purpose (future requirement) could
> > be to send some signal to syslogger in restart path so that it can release
> > the shared memory handle.
>
> +#ifdef EXEC_BACKEND
> + if (!CloseHandle(UsedShmemSegID))
> + elog(LOG, "could not close handle to shared memory: error
> code %lu", GetLastError());
> +#endif
> I am pretty sure that you would want a WIN32 block here, not
> EXEC_BACKEND as the latter can be used on non-Windows platforms as
> well to emulate Windows behavior.
>
Agreed, I can change the patch to use WIN32, but it seems not all
people want to follow this approach. So lets first try to see what