Eliminate one background-worker-related flag variable.

Teach sigusr1_handler() to use the same test for whether a worker
might need to be started as ServerLoop().  Aside from being perhaps
a bit simpler, this prevents a potentially-unbounded delay when
starting a background worker.  On some platforms, select() doesn't
return when interrupted by a signal, but is instead restarted,
including a reset of the timeout to the originally-requested value.
If signals arrive often enough, but no connection requests arrive,
sigusr1_handler() will be executed repeatedly, but the body of
ServerLoop() won't be reached.  This change ensures that, even in
that case, background workers will eventually get launched.

This is far from a perfect fix; really, we need select() to return
control to ServerLoop() after an interrupt, either via the self-pipe
trick or some other mechanism.  But that's going to require more
work and discussion, so let's do this for now to at least mitigate
the damage.

Per investigation of test_shm_mq failures on buildfarm member anole.
This commit is contained in:
Robert Haas 2014-10-04 21:25:41 -04:00
parent 513d06ded1
commit d0410d6603

View File

@ -4752,7 +4752,6 @@ static void
sigusr1_handler(SIGNAL_ARGS)
{
int save_errno = errno;
bool start_bgworker = false;
PG_SETMASK(&BlockSig);
@ -4760,7 +4759,7 @@ sigusr1_handler(SIGNAL_ARGS)
if (CheckPostmasterSignal(PMSIGNAL_BACKGROUND_WORKER_CHANGE))
{
BackgroundWorkerStateChange();
start_bgworker = true;
StartWorkerNeeded = true;
}
/*
@ -4801,10 +4800,10 @@ sigusr1_handler(SIGNAL_ARGS)
pmState = PM_HOT_STANDBY;
/* Some workers may be scheduled to start now */
start_bgworker = true;
StartWorkerNeeded = true;
}
if (start_bgworker)
if (StartWorkerNeeded || HaveCrashedWorker)
maybe_start_bgworker();
if (CheckPostmasterSignal(PMSIGNAL_WAKEN_ARCHIVER) &&