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 | 24993.1258040745@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: recovery is stuck when children are not processing SIGQUIT from previous crash (Marko Kreen <markokr@gmail.com>) |
Ответы |
Re: recovery is stuck when children are not processing
SIGQUIT from previous crash
Re: recovery is stuck when children are not processing SIGQUIT from previous crash |
Список | pgsql-admin |
Marko Kreen <markokr@gmail.com> writes: > You talked about blocking in quickdie(), but you'd need > to block in elog(). I'm not really particularly worried about that case. By that logic, we could not use quickdie at all, because any part of the system might be doing something that wouldn't survive being interrupted. In practice the code path isn't sufficiently used or critical enough to be worth trying to make that bulletproof. It does strike me that we might someday add code to the postmaster to SIGKILL processes that fail to exit in a reasonably prompt fashion after SIGQUIT, on the theory that they might be stuck in something like this. But for now, I'm more interested in a one-line fix that will deal with the actually observed case ... regards, tom lane
В списке pgsql-admin по дате отправления: