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

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Marcin Waldowski <M(dot)Waldowski(at)sulechow(dot)net>, pgsql-bugs(at)postgresql(dot)org, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BUG #3242: FATAL: could not unlock semaphore: error code 298
Date: 2007-04-20 16:46:09
Message-ID: 4628EE51.70205@hagander.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2007-04-20 16:55:00 Re: BUG #3242: FATAL: could not unlock semaphore: error code 298
Previous Message Tom Lane 2007-04-20 16:14:07 Re: BUG #3245: PANIC: failed to re-find shared lock object

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-04-20 16:55:00 Re: BUG #3242: FATAL: could not unlock semaphore: error code 298
Previous Message Heikki Linnakangas 2007-04-20 15:21:09 Re: Dead Space Map version 3 (simplified)