Re: recovery is stuck when children are not processing SIGQUIT from previous crash
В списке pgsql-admin по дате отправления:
| От | Marko Kreen |
|---|---|
| Тема | Re: recovery is stuck when children are not processing SIGQUIT from previous crash |
| Дата | |
| Msg-id | e51f66da0911121237s6d0f0316sde11e4a3e6038b8b@mail.gmail.com обсуждение |
| Ответ на | Re: recovery is stuck when children are not processing SIGQUIT from previous crash (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-admin |
On 11/12/09, Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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. Not really - we'd need to care only about parts that quickdie() (or any other signal handler) wants to use. Which basically means elog() only. OK, full elog() is a beast, but why would SIGQUIT handler need full elog()? How about we export minimal log-writing function and make that signal-safe - that is, drop message if already active. This will excange potential crash/deadlock with lost msg which seems slightly better behaviour. -- marko
В списке pgsql-admin по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера