On Sun, Oct 11, 2015 at 5:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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?
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.
