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

From: Marcin Waldowski <M(dot)Waldowski(at)sulechow(dot)net>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-21 21:07:08
Message-ID: 462A7CFC.5070706@sulechow.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Magnus Hagander wrote:
> Tom Lane wrote:
>
>> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>>
>>> No, it's definitly the right primitive. But we're creating it with a max
>>> count of 1.
>>>
>> That's definitely wrong. There are at least three reasons for a PG
>> process's semaphore to be signaled (heavyweight lock release, LWLock
>> release, pin count waiter), and at least two of them can occur
>> concurrently (eg, if deadlock checker fires, it will need to take
>> LWLocks, but there's nothing saying that the original lock won't be
>> released while it waits for an LWLock).
>>
>> The effective max count on Unixen is typically in the thousands,
>> and I'd suggest the same on Windows unless there's some efficiency
>> reason to keep it small (in which case, maybe ten would do).
>>
>
> AFAIK there's no problem with huge numbers (it takes an int32, and the
> documentation says nothing about a limit - I'm sure it's just a 32-bit
> counter in the kernel). I'll give that a shot.
>

Magnus, Tom, thank you for finding what causes the problem :) I hope
that was also a reason why other transactions were hung (because that is
a prior, I think).

> Marcin - can you test a source patch? Or should I try to build you a
> binary for testing? It'd be good if you can confirm that it works before
> we commit anything, I think.
>

Of course I will check fix :) I will be able to do tests on monday. I
think source path should be enought, despite I've newer build PostgreSQL
on Windows (I definitely should try). If i have problems then I will ask
you for binary.

Regards, Marcin

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2007-04-22 02:23:30 Re: BUG #3245: PANIC: failed to re-find shared loc k ob ject
Previous Message Dorochevsky,Michel 2007-04-21 19:38:35 Re: BUG #3245: PANIC: failed to re-find shared loc k ob ject

Browse pgsql-hackers by date

  From Date Subject
Next Message Gustavo Tonini 2007-04-21 21:37:44 Re: Fragmentation project
Previous Message Tom Lane 2007-04-21 16:45:15 Re: 27 second plan times