Re: [HACKERS] backend freezeing on win32 fixed (I hope ;-) )

Got it.

> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
> >> 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.
>
> > Seems we may have to use the patch, or make some other patch for NT-only
> > that works around this NT bug.
>
> I don't have a problem with installing an NT patch (lord knows there
> are plenty of #ifdef __CYGWIN32__'s in the code already). But I have
> a problem with *this* patch because I don't believe we understand what
> it is doing, and therefore I have no confidence in it. The extent of
> our understanding so far is that one backend can create a semaphore that
> can be used by a later backend, but the postmaster cannot create a
> semaphore that can be used by a later backend. I don't really believe
> that; I think there is something else going on. Until we understand
> what the something else is, I don't think we have a trustworthy
> solution.
>
> The real reason I feel itchy about this is that I know that interprocess
> synchronization is a very tricky area, so I'm not confident that the
> limited amount of testing Dan can do by himself proves that things are
> solid. As the old saw goes, "testing cannot prove the absence of bugs".
> I want to have both clean test results *and* an understanding of what
> we are doing before I will feel comfortable.
>
> Looking again at the code, it occurs to me that a backend exiting
> normally will probably leave its semaphore set nonzero, which could
> (given a buggy IPC library) have something to do with whether another
> process can attach to the sema or not. The postmaster code is *trying*
> to create the semas with nonzero starting values, but I see that the
> backend code takes the additional step of doing
> semun.val = IpcSemaphoreDefaultStartValue;
> semctl(semId, semNum, SETVAL, semun);
> whereas the postmaster code doesn't. Maybe the create call isn't
> initializing the semaphores the way it's told to? It'd be worth
> trying adding a step like this to the postmaster preallocation.
>
> In any case, I'd really like us to get some feedback from the author of
> cygipc about this issue. I don't mind working around a bug once we
> understand exactly what the bug is --- but in this particular area,
> I think guessing our way to a workaround isn't good enough.
>
> regards, tom lane
>

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026