Re: SIGUSR1 pingpong between master na autovacum launcher causes crash - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SIGUSR1 pingpong between master na autovacum launcher causes crash
Date
Msg-id 10974.1250890712@sss.pgh.pa.us
Whole thread Raw
In response to Re: SIGUSR1 pingpong between master na autovacum launcher causes crash  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: SIGUSR1 pingpong between master na autovacum launcher causes crash  (Alvaro Herrera <alvherre@commandprompt.com>)
List 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 by date:

Previous
From: Jean-Michel Pouré
Date:
Subject: Re: Feedback about Drupal SQL debugging
Next
From: Alvaro Herrera
Date:
Subject: Re: SIGUSR1 pingpong between master na autovacum launcher causes crash