On Tue, Oct 13, 2015 at 8:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Michael Paquier <michael.paquier@gmail.com> writes: > > On Tue, Oct 13, 2015 at 5:35 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> After poking around a bit more, I propose the attached patch. I've > >> checked that this is happy with an EXEC_BACKEND Unix build, but I'm not > >> able to test it on Windows ... would somebody do that? > > > Looking at the patch, clearly +1 for the additional routine in both > > win32_shmem.c and sysv_shmem.c to clean up the shmem state at backend > > level. I have played as well with the patch on Windows and it behaves > > as expected: without the patch a process killed with taskkill /f stops > > straight the server even if restart_on_crash is on. With the patch the > > server restarts correctly. > > OK, pushed with some additional comment-smithing. > > I noticed while looking at this that for subprocesses that aren't supposed > to be attached to shared memory, we do pgwin32_ReserveSharedMemoryRegion() > anyway in internal_forkexec(), and then that's never undone anywhere, > so that that segment of the subprocess's memory space remains reserved. > I'm not sure if this is worth changing, but if it is, we could do so now > by calling VirtualFree() in PGSharedMemoryNoReAttach(). >
I think it is worth doing, as it can save the memory for processes which
don't attach to shared memory. Another thing is that we do allocate
handles (by using duplicate handle) in save_backend_variables() which
I am not sure are required for all the processes, anyway this doesn't
seem worth the trouble.
> BTW, I am suspicious that the DSM stuff may have related issues --- do > we use inheritable mapping handles for DSM segments on Windows? >
Not by default, there is an API dsm_pin_segment() which Duplicates the
handle for Postmaster process to retain the shared memory segment
till Postmaster shutdown. In general, I don't see such issues for DSM,
but please point me if you see anything problematic.
