> > > In any case, when one backend quits and another one is
> > > started, the new
> > > one will re-use the semaphore no longer used by the
> defunct backend.
> >
> > I have tested my solution a bit more and I have to say that
> reusing a
> > semaphore by a new backend works OK. But it is not possible
> for a newly
> > created backend to use a semaphore allocated by postmaster
> (it freezes on
> > test if the semaphore with given key already exists - done with
> > semId=semget(semKey, 0, 0) in function IpcSemaphoreCreate() in
> > storage/ipc/ipc.c ). Why it is, I don't know, but it seems that
> > my solution
> > uses the ipc library in the right way. There are no longer any error
> > messages from the ipc library when running the server. And I
> > can't say that
> > the ipc library is a 100% correct implementation of SysV IPC, it
> > is probably
> > (sure ;-) )caused by the Windows internals.
> >
>
> Yutaka Tanida [yutaka@marin.or.jp] and I have examined IPC
> library.
>
> We found that postmaster doesn't call exec() after fork() since v6.4.
>
> The value of static/extern variables which cygipc library holds may
> be different from their initial values when postmaster fork()s child
> backend processes.
>
> I made the following patch for cygipc library on trial.
> This patch was effective for Yutaka's test case.
I will try it right now, it looks interesting. It could also explain some
"non-deterministic" behavior of the cygipc library.
Dan