Re: stuck spin lock with many concurrent users - Mailing list pgsql-hackers

From Tom Lane
Subject Re: stuck spin lock with many concurrent users
Date
Msg-id 2360.993178880@sss.pgh.pa.us
Whole thread Raw
In response to Re: stuck spin lock with many concurrent users  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Responses Re: stuck spin lock with many concurrent users  (Tatsuo Ishii <t-ishii@sra.co.jp>)
List pgsql-hackers
Tatsuo Ishii <t-ishii@sra.co.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


pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: stuck spin lock with many concurrent users
Next
From: Alex Pilosov
Date:
Subject: [ANNOUNCE] DBD::PgSPI