On Sun, Oct 11, 2015 at 10:09 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Dmitry Vasilyev <d.vasil...@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.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
