Re: Postgres service stops when I kill client backend on Windows - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Postgres service stops when I kill client backend on Windows
Date
Msg-id 49495.1444576975@sss.pgh.pa.us
Whole thread Raw
In response to Re: Postgres service stops when I kill client backend on Windows  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Postgres service stops when I kill client backend on Windows  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.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?

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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Postgres service stops when I kill client backend on Windows
Next
From: Magnus Hagander
Date:
Subject: Re: Postgres service stops when I kill client backend on Windows