> Good luck figuring out where the real problem is...
>
> regards, tom lane
Well, thanks to tom, I know what was wrong, and I have found the problem,
or one of them at least...
FATAL: s_lock(0c9ef824) at bufmgr.c:1106, stuck spinlock. Aborting.
Okee, that segment of code is, well, its some deep down internals that
are as clear as mud to me.
Anyone in the know have an idea what this does?
Just to save you looking, it is included below.
One question, is that does postgresql Inc have a 'normal person' support
level? I ask that cos I was planning on getting some of the commercial
support, and whilst it is a reasonable price to pay for corporations or
people with truckloads of money, I am a humble developer with more
expenses than income, and $600 is just way out of my league {:-(
If not, fair enough, just thought Id ask cos the support I have had from
this list is excellent and I wanted to provide some payback to the
developoment group.
~Michael
/** WaitIO -- Block until the IO_IN_PROGRESS flag on 'buf'* is cleared. Because IO_IN_PROGRESS conflicts
are* expected to be rare, there is only one BufferIO* lock in the entire system. All
processesblock* on this semaphore when they try to use a buffer* that someone else is
faultingin. Whenever a* process finishes an IO and someone is waiting for* the buffer,
BufferIOis signaled (SignalIO). All* waiting processes then wake up and check to see* if
theirbuffer is now ready. This implementation* is simple, but efficient enough if WaitIO is*
rarelycalled by multiple processes simultaneously.** ProcSleep atomically releases the spinlock and goes to*
sleep.** Note: there is an easy fix if the queue becomes long.* save the id of the buffer we
arewaiting for in* the queue structure. That way signal can figure* out which proc to wake
up.*/
#ifdef HAS_TEST_AND_SET
static void
WaitIO(BufferDesc *buf, SPINLOCK spinlock)
{ SpinRelease(spinlock); S_LOCK(&(buf->io_in_progress_lock)); S_UNLOCK(&(buf->io_in_progress_lock));
SpinAcquire(spinlock);
}