| От | Tom Lane |
|---|---|
| Тема | Re: s_lock_stuck (was Problems w/ LO) |
| Дата | |
| Msg-id | 16502.928179594@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Problems w/ LO (Tatsuo Ishii <t-ishii@sra.co.jp>) |
| Список | pgsql-hackers |
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> I've been looking into the "stuck spin lock" problem under high
> load. Unless it being solved, PostgreSQL would not be usable in the
> "real world."
> Question to hackers: Why does s_lock_stuck() call abort()? Shouldn't
> be elog(ERROR) or elog(FATAL)?
I think that is probably the right thing. elog(ERROR) will not do
anything to release the stuck spinlock, and IIRC not even elog(FATAL)
will. The only way out is to clobber all the backends and reinitialize
shared memory. The postmaster will not do that unless a backend dies
without making an exit report --- which means doing abort().
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера