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:48:11
Message-ID: 20090821214811.GP5487@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 failed to 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2009-08-21 22:02:46 Re: GRANT ON ALL IN schema
Previous Message Tom Lane 2009-08-21 21:38:32 Re: SIGUSR1 pingpong between master na autovacum launcher causes crash