Dmitry Vasilyev <d.vasil...@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.6080...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
