Michael <michael@gameservice.ru> writes:
> TL> How repeatable is this --- does it happen on every connection attempt,
> TL> or only sometimes? Can you start and stop the postmaster without
> TL> any problems being logged?
> Only sometimes, 1-4 times per day under high load. Postmaster starts
> and stops without problems.
You should have been clear about that to start with, because it
changes the likely nature of the problem entirely.
> Backtraces are a bit different from time to time, here is last:
Hmm, are they always within InitPostgres? That would be a bit odd,
because I can't see any reason why a recently-started process would
be more prone to a transient spinlock problem than any other process.
What seems like a reasonable bet at this point is that the FBSD7
kernel's scheduler has been changed in a way that makes it possible for
it to sometimes not schedule a process for a very long time (order of a
couple minutes). If that happened while the process was holding a
spinlock then other processes waiting to get the spinlock would fail
like this. Since we don't hold spinlocks long --- the maximum hold time
is supposed to be no more than a couple dozen instructions --- the
probability of this would be low. But under sufficient load maybe you'd
see it a few times a day. (What is "high load" to you, anyway?)
A different theory, given that you said you're using a dual-core
machine, is that we're seeing the effects of the two CPUs' caches
somehow getting out of sync. I could believe that a kernel problem
could cause that; wrong settings in the hardware page tables, for
instance. Dunno if you can afford the performance hit, but it would be
interesting to run for awhile with only one CPU active and see if the
problem still occurs.
Anyway, I think you probably need to get some FBSD kernel hackers
involved, because this sounds to me like it's their bug in one way
or another. Particularly since I now notice you mentioned that FBSD7
is only at beta1 stage ...
regards, tom lane