Re: [BUGS] BUG #3242: FATAL: could not unlock semaphore: error code 298 - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: [BUGS] BUG #3242: FATAL: could not unlock semaphore: error code 298
Date
Msg-id 4628EE51.70205@hagander.net
Whole thread Raw
In response to Re: [BUGS] BUG #3242: FATAL: could not unlock semaphore: error code 298  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [BUGS] BUG #3242: FATAL: could not unlock semaphore: error code 298
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: [BUGS] BUG #3242: FATAL: could not unlock semaphore: error code 298
Next
From: Tom Lane
Date:
Subject: Re: [BUGS] BUG #3242: FATAL: could not unlock semaphore: error code 298