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
