On Tue, Oct 13, 2015 at 5:35 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote: >> This is kind of a mess :-(. But it does look like what we want is >> for SubPostmasterMain to do more than nothing when it chooses not to >> reattach. Probably that should include resetting UsedShmemSegAddr to >> NULL, as well as closing the handle. > > 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? > > BTW, it appears from this that Cygwin builds have been broken right along > in a different way: according to the code in sysv_shmem's > PGSharedMemoryReAttach, Cygwin does cause a re-attach to occur, which we > were not undoing for putatively-not-connected-to-shmem child processes. > That's a robustness problem because it breaks the postmaster's expectation > that it's safe to not reinitialize shmem after a crash of one of those > processes. I believe this patch fixes that problem as well, though if > anyone can test it on Cygwin that wouldn't be a bad thing either.
I don't have a Cygwin environment at hand. That's unfortunate.. 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. (Sorry, I should have mentioned that my last patch was untested and *surely broken*, that was the result of a 3-min guess to make the cleanup more generic for child processes that do not need to be attached to shmem). Regards, -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers