Re: stuck spin lock with many concurrent users

Поиск
Список
Период
Сортировка
От Tatsuo Ishii
Тема Re: stuck spin lock with many concurrent users
Дата
Msg-id 20010622122422E.t-ishii@sra.co.jp
обсуждение исходный текст
Ответ на Re: stuck spin lock with many concurrent users  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: stuck spin lock with many concurrent users  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Re: stuck spin lock with many concurrent users  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Список 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.

Nice idea. I will try that.
--
Tatsuo Ishii


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alex Pilosov
Дата:
Сообщение: [ANNOUNCE] DBD::PgSPI
Следующее
От: Alex Pilosov
Дата:
Сообщение: SPI_prepare for semi-unknown types