On Mon, Oct 12, 2015 at 8:10 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > I wrote: > > Andres Freund <and...@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. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
