Re: SIGUSR1 pingpong between master na autovacum launcher causes crash

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: SIGUSR1 pingpong between master na autovacum launcher causes crash
Дата
Msg-id 10974.1250890712@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: SIGUSR1 pingpong between master na autovacum launcher causes crash  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: SIGUSR1 pingpong between master na autovacum launcher causes crash
Список pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane wrote:
>> It does seem that we ought to change things so that there's a bit more
>> delay before trying to re-launch a failed autovac worker, though.
>> Whatever caused this was effectively turning the autovac logic into
>> a fork-bomb engine.  I'm not thinking of just postponing the relaunch
>> into the main loop, but ensuring at least a few hundred msec delay before
>> we try again.

> Would it be enough to move the kill() syscall into ServerLoop in
> postmaster.c instead of letting it be called in the signal handler, per
> the attached patch?  This way the signal is not delayed, but we exit the
> signal handler before doing it.

I'd still like to have some fork-rate-limiting behavior in there
somewhere.  However, it might make sense for the avlauncher to do that
rather than the postmaster.  Does that idea seem more implementable?

(If the launcher implements a minimum delay between requests then it
really doesn't matter whether we apply this patch or not, and I'd be
inclined to leave the postmaster alone rather than add yet more state.)
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jean-Michel Pouré
Дата:
Сообщение: Re: Feedback about Drupal SQL debugging
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: SIGUSR1 pingpong between master na autovacum launcher causes crash