Re: stuck spin lock with many concurrent users

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: stuck spin lock with many concurrent users
Date: 2001-06-22 03:01:20
Message-ID: 2360.993178880@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
>>> How can I check it?
>>
>> The 'stuck' message should at least give you a code location...

> FATAL: s_lock(0x2ac2d016) at spin.c:158, stuck spinlock. Aborting.

Hmm, that's SpinAcquire, so it's one of the predefined spinlocks
(and not, say, a buffer spinlock). You could try adding some
debug logging here, although the output would be voluminous.
But what would really be useful is a stack trace for the stuck
process. Consider changing the s_lock code to abort() when it
gets a stuck spinlock --- then you could gdb the coredump.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alex Pilosov 2001-06-22 03:16:14 [ANNOUNCE] DBD::PgSPI
Previous Message Tatsuo Ishii 2001-06-22 02:31:05 Re: stuck spin lock with many concurrent users