Re: [BUGS] BUG #3242: FATAL: could not unlock semaphore: error code 298

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: [BUGS] BUG #3242: FATAL: could not unlock semaphore: error code 298
Дата
Msg-id 4628EE51.70205@hagander.net
обсуждение исходный текст
Ответ на Re: [BUGS] BUG #3242: FATAL: could not unlock semaphore: error code 298  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [BUGS] BUG #3242: FATAL: could not unlock semaphore: error code 298  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> On Fri, Apr 20, 2007 at 09:20:05AM +0200, Marcin Waldowski wrote:
>>>> I've looked at the code there, and can't find a clear problem. One way it
>>>> could happen is if the actual PGSemaphoreUnlock() is called once more than
>>>> needed. 
> 
>> CC:ing to hackers for this question:
> 
>> Any chance that's happening? If this happens with SysV semaphores, will
>> they error out, or just say it was done and do nothing? (meaning should we
>> actuallyi be ignoring this error on windows?)
> 
> How is it possible for a semaphore to be unlocked "too many times"?
> It's supposed to be a running counter of the net V's minus P's, and
> yes it had better be able to count higher than one.  Have we chosen
> the wrong Windows primitive to implement this?

No, it's definitly the right primitive. But we're creating it with a max
count of 1. Not sure if that's right or not, too tired to think straight
about that right now, but here's a summary:

* Object is "signalled" when count > 0.

* We create with an initial count of 1.

* Calling WaitFor...() decreases the count. We call waitFor() in
PGsemaphoreLock(). If count reaches zero, waitfor() will block.

* Calling ReleaseSemaphore() increases the count. If count leaves zero
for 1, a blocking waitfor() is released. If count ends up >1 (or
whatever the limit is set to), we get said error. We call
ReleaseSemaphore() in PGSemaphoreUnlock().


So basically this says we've called PGSemaphoreUnlock() more times than
we've called PGSemaphoreLock().


Should we be creating it with a higher maximum value, and that's it? (it
sounds like it, but I'm not entirely sure)

//Magnus


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [BUGS] BUG #3242: FATAL: could not unlock semaphore: error code 298
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [BUGS] BUG #3242: FATAL: could not unlock semaphore: error code 298