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

From Alvaro Herrera
Subject Re: SIGUSR1 pingpong between master na autovacum launcher causes crash
Date
Msg-id 20090821214811.GP5487@alvh.no-ip.org
Whole thread Raw
In response to Re: SIGUSR1 pingpong between master na autovacum launcher causes crash  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SIGUSR1 pingpong between master na autovacum launcher causes crash  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: SIGUSR1 pingpong between master na autovacum launcher causes crash  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
List pgsql-hackers
Tom Lane wrote:

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

Well, there's already rate limiting in the launcher:

        if (AutoVacuumShmem->av_signal[AutoVacForkFailed])        {            /*             * If the postmaster
failedto start a new worker, we sleep             * for a little while and resend the signal.  The new worker's
   * state is still in memory, so this is sufficient.  After             * that, we restart the main loop.
*            * XXX should we put a limit to the number of times we retry?             * I don't think it makes much
sense,because a future start             * of a worker will continue to fail in the same way.             */
AutoVacuumShmem->av_signal[AutoVacForkFailed]= false;            pg_usleep(100000L);        /* 100ms */
SendPostmasterSignal(PMSIGNAL_START_AUTOVAC_WORKER);           continue;        }
 

Does it just need a longer delay?

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: SIGUSR1 pingpong between master na autovacum launcher causes crash
Next
From: Petr Jelinek
Date:
Subject: Re: GRANT ON ALL IN schema