Re: recovery is stuck when children are not processing SIGQUIT from previous crash

Поиск
Список
Период
Сортировка
От 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 по дате отправления:

Предыдущее
От: Marko Kreen
Дата:
Сообщение: Re: recovery is stuck when children are not processing SIGQUIT from previous crash
Следующее
От: Marko Kreen
Дата:
Сообщение: Re: recovery is stuck when children are not processing SIGQUIT from previous crash