Re: Postgres service stops when I kill client backend on Windows
От | Tom Lane |
---|---|
Тема | Re: Postgres service stops when I kill client backend on Windows |
Дата | |
Msg-id | 49495.1444576975@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Postgres service stops when I kill client backend on Windows (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Postgres service stops when I kill client backend on Windows
|
Список | 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 по дате отправления: