Обсуждение: 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

Horak Daniel <horak@mmp.plzen-city.cz> writes:
>> 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.

> 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.

Yes.  The way the code used to work (pre 6.5) was that the first backend
to fire up would grab a block of 16 semaphores, which would be used by
backends 2-16; when you started a 17'th concurrent backend another block
of 16 semaphores would be grabbed; etc.  The code you diked out simply
forces preallocation of a bunch of semaphores at postmaster start time,
rather than having it done by selected backends.  That's why it doesn't
make any sense to me that removing it would fix anything --- you'll
still have backends dependent on semaphores that were created by other
processes, it's just that they were other backends instead of the
postmaster.

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.
        regards, tom lane