| От | Petr Jelinek |
|---|---|
| Тема | Re: bgworker crashed or not? |
| Дата | |
| Msg-id | 536A426A.9080708@2ndquadrant.com обсуждение |
| Ответ на | Re: bgworker crashed or not? (Petr Jelinek <petr@2ndquadrant.com>) |
| Список | pgsql-hackers |
On 07/05/14 02:25, Petr Jelinek wrote: > On 06/05/14 19:05, Robert Haas wrote: >> What I'm inclined to do is change the logic so that: >> >> (1) After a crash-and-restart sequence, zero rw->rw_crashed_at, so >> that anything which is still registered gets restarted immediately. > > Yes, that's quite obvious change which I missed completely :). > >> (2) If a shmem-connected backend fails to release the deadman switch >> or exits with an exit code other than 0 or 1, we crash-and-restart. A >> non-shmem-connected backend never causes a crash-and-restart. > > +1 > >> (3) When a background worker exits without triggering a >> crash-and-restart, an exit code of precisely 0 causes the worker to be >> unregistered; any other exit code has no special effect, so >> bgw_restart_time controls. > > +1 > Ok, attached patch is my try at the proposed changes. I don't like the reset_bgworker_crash_state function name, maybe you'll come up with something better... I passes my tests for the desired behavior, hopefully I didn't miss some scenario. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера