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
Re: stuck spin lock with many concurrent users |
Список | 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 по дате отправления: