Re: SIGUSR1 pingpong between master na autovacum launcher causes crash

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SIGUSR1 pingpong between master na autovacum launcher causes crash
Date: 2009-08-21 21:38:32
Message-ID: 10974.1250890712@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)commandprompt(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2009-08-21 21:48:11 Re: SIGUSR1 pingpong between master na autovacum launcher causes crash
Previous Message Jean-Michel Pouré 2009-08-21 21:34:57 Re: Feedback about Drupal SQL debugging