Re: SIGUSR1 pingpong between master na autovacum launcher causes crash

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:33:15
Message-ID: 20090821213315.GO5487@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > If sigusr1_handler needs rewriting, don't all the other sighandler as
> > well?
>
> It does not, and neither do they. I'm not sure what happened here but
> it wasn't the fault of the postmaster's organization of signal handlers.
>
> 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.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Attachment Content-Type Size
autovac-signal.patch text/x-diff 2.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jean-Michel Pouré 2009-08-21 21:34:57 Re: Feedback about Drupal SQL debugging
Previous Message Tom Lane 2009-08-21 20:19:43 Re: Feedback about Drupal SQL debugging