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
> >> 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

Reply via email to