On Sun, Oct 11, 2015 at 10:09 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Dmitry Vasilyev <d.vasilyev@postgrespro.ru> writes: > > 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. > .. > > 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. >
There is some possibility based on the above DEBUG messages that
DSM could cause this problem, but I think the last message (pre-existing
shared memory block is still in use) won't be logged for DSM. We create
the new dsm segment in below code dsm_postmaster_startup()->
dsm_impl_op()->dsm_impl_windows()
dsm_impl_windows()
{
..
if (op == DSM_OP_CREATE) ..
}
Basically in this path, we try to recreate the dsm with different name if it
fails with ALREADY_EXIST error.
To diagnose the reason of problem, I think we can write a diagnostic
patch which would do below 2 points:
1. Increase the below loop count 10 to 50 or 100 in win32_shmem.c
or instead of loop count, we can increase the sleep time as well.
PGSharedMemoryCreate() { .. for (i = 0; i < 10; i++) ..
if (GetLastError() == ERROR_ALREADY_EXISTS) { .. Sleep(1000); continue; }
..
}
2. Increase the log messages both in win32_shmem.c and dsm related
code which can help us in narrowing down the problem.
If you find this as reasonable approach to diagnose the root cause
of problem, I can work on writing a diagnostic patch.
