Re: Postgres service stops when I kill client backend on Windows

On Sun, Oct 11, 2015 at 5:22 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> > Amit's proposals elsewhere to increase the shmem timeout and increase
> > logging seem reasonable.
>
> I'm back to the position I had in the previous thread, which is that
> we don't really understand why any delay is needed here at all, and
> we ought to try to remedy that lack rather than just hoping that more
> and more delay will fix it. It may be that there's some proactive
> measure we can take to improve matters.
>
> I'm a bit suspicious that we may have leaked a handle to the shared
> memory block someplace, for example. That would explain why this
> symptom is visible now when it was not in 2009. Or maybe it's dependent
> on some feature that we didn't test back then --- for instance, if
> the logging collector is in use, could it have inherited a handle and
> not closed it?
>

Even if we leaked it, it should go away when the other processes died.

What would be interesting to know is if there at this point is *any*
postgres.exe process still running, and in that case what it is. It should
then be possible to use Process Explorer to figure out which process it is
(by looking at the "fake title"), and probably also which shared memory
handles it has open (even though they don't have a name, their info might
explain things).

So if someone with a reproducible case could check that as well, I think it
woudl be valuable information.

> One thing I noticed in the CreateFileMapping docs is that Windows
> apparently implements the sort of anonymous mapping we're doing as
> a mapping of part of the "system paging file". I wonder if it's too
> dumb (perhaps in only some releases) to realize that it doesn't
> really need to flush dirty pages to disk when the last reference
> to the mapping is abandoned. In that case maybe an explicit flush
> request would move things along.
>
>
First of all, note that "system paging file" is exactly the same as "swap
file" or "swap partition" on Unix. Just in case there is any unclearness
there.

And I'm pretty sure it doesn't do that. Surely we would've seen performance
issues from that before in that case. But I don't really have any facts to
back that up :)

We do get, AIUI, the SEC_COMMIT behaviour which commits the pages initially
to make sure there is actually space for them. I don't believe that one
specifically says anything about when you close it.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/