Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
