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 |
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 |