| От | Tom Lane |
|---|---|
| Тема | Re: stuck spin lock with many concurrent users |
| Дата | |
| Msg-id | 2360.993178880@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
|
| Список | 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 по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера