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 | 49161.1444538399@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Postgres service stops when I kill client backend on Windows (Dmitry Vasilyev <d.vasilyev@postgrespro.ru>) |
Ответы |
Re: Postgres service stops when I kill client backend on Windows
|
Список | pgsql-hackers |
Dmitry Vasilyev <d.vasilyev@postgrespro.ru> writes: > On Сб, 2015-10-10 at 10:55 -0500, Tom Lane wrote: >> and (b) you still haven't convinced me that you had an actual service >> stop, and not just that the recovery time was longer than psql would >> wait before retrying the connection. > The log you can see bellow: > ... > 2015-10-10 19:00:32 AST DEBUG: cleaning up dynamic shared memory control segment with ID 851401618 > 2015-10-10 19:00:32 AST DEBUG: invoking IpcMemoryCreate(size=290095104) > 2015-10-10 19:00:42 AST FATAL: pre-existing shared memory block is still in use > 2015-10-10 19:00:42 AST HINT: Check if there are any old server processes still running, and terminate them. Thanks for providing some detail! It's clear from the above log excerpt that we're timing out after 10 seconds in win32_shmem.c's version of PGSharedMemoryCreate, because CreateFileMapping is still reporting that the old shared memory segment still exists. When we last discussed this sort of problem in http://www.postgresql.org/message-id/flat/49FA3B6F.6080906@dunslane.net there was no evidence that such a failure could persist for longer than a second or two. Now it seems that on your machine the failure state can persist for at least 10 seconds, but I don't know why. If I had to guess, on the basis of no evidence, I'd wonder whether the DSM code broke it; there is evidently at least one DSM segment in play in your use-case. But that's only a guess. regards, tom lane
В списке pgsql-hackers по дате отправления: