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

> They should never be "initialized a second time". And the
> preallocation
> is *not* for performance reasons, it is to make sure we can
> actually get
> enough semaphores (rather than dying under load when we fail
> to get the
> N+1'st semaphore when starting the N+1'st backend).
>
> > The fix (made for v6.5.1) is here:
> > [ Fix consists of diking out preallocation of semaphores by
> postmaster ]
>
> I do not like this patch one bit --- I think it is voodoo that doesn't
> really have anything to do with the true problem. I don't know what
> the true problem is, mind you, but I don't think this is the way to
> fix it.

I know it is not a perfect solution but now it is better than nothing.

>
> Is it possible that the CygWin environment doesn't have a correct
> emulation of IPC semaphores, such that a sema allocated by one process

It seems that there is really a problem in the IPC for cygwin, but I am not
an expert in Windows programming and internals so it is hard for me to make
a better one. But I will try to correct the IPC library.

> (the postmaster) is not available to other procs (the backends)?
> That would explain preallocation not working --- but if that's it then
> we have major problems in other places, since the code assumes that a
> sema once allocated will remain available to later backends.

Does this mean that when I have one connection to the server, I end it and
start a new one, this new one will use the same semaphores? But it seems to
work.

Can disabling the semaphores prealocation have some negative effects on the
correct function of the backend?

Dan