On Mon, Oct 12, 2015 at 8:10 PM, Tom Lane <
tgl@sss.pgh.pa.us> wrote:
>
> I wrote:
> > Andres Freund <
andres@anarazel.de> writes:
> >> Right. But that doesn't mean it's right to call PGSharedMemoryDetach()
> >> without other changes as done in Michael's proposed patch? That'll do an
> >> UnmapViewOfFile() which'll fail because nothing i mapped, but still not
> >> close UsedShmemSegID?
>
> > Ah, right, I'd not noticed that he proposed changing
> > CloseHandle(UsedShmemSegID) to PGSharedMemoryDetach(). The latter is
> > clearly the wrong thing.
>
> Actually, now that I look at it, it's even more obvious that this is the
> wrong thing because *all the subprocess types in question already call
> PGSharedMemoryDetach*. That's necessary on Unix, but I should think that
> on Windows all it will do is provoke the log message:
>
> elog(LOG, "could not unmap view of shared memory: error code %lu", GetLastError());
>
> Could someone confirm whether syslogger, archiver, stats collector
> processes reliably produce that log message at startup on Windows?
>
I have tried this approach of calling PGSharedMemoryDetach() for
syslogger before calling closehandle() patch and I saw that message
and understood that it is not going to work.
