Re: recovery is stuck when children are not processing SIGQUIT from previous crash
В списке pgsql-admin по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: recovery is stuck when children are not processing SIGQUIT from previous crash |
| Дата | |
| Msg-id | 23748.1258036538@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: recovery is stuck when children are not processing SIGQUIT from previous crash (Peter Eisentraut <peter_e@gmx.net>) |
| Ответы |
Re: recovery is stuck when children are not processing
SIGQUIT from previous crash
|
| Список | pgsql-admin |
Peter Eisentraut <peter_e@gmx.net> writes:
>>> strace on the backend processes all showed them waiting at
>>> futex(0x7f1ee5e21c90, FUTEX_WAIT_PRIVATE, 2, NULL
>>> Notably, the first argument was the same for all of them.
> Looks like a race condition or lockup in the syslog code.
Hm, why are there two <signal handler> calls in the stack?
The only thing I can think of is that we sent SIGQUIT twice.
That's probably bad --- is there any obvious path through
the postmaster that would do that?
The other thought is that quickdie should block signals before
starting to do anything.
regards, tom lane
В списке pgsql-admin по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера