On Mon, 2008-11-17 at 16:18 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > @@ -3845,6 +3850,52 @@ sigusr1_handler(SIGNAL_ARGS)
> >
> > PG_SETMASK(&BlockSig);
> >
> > + if (CheckPostmasterSignal(PMSIGNAL_RECOVERY_START))
> > + {
> > + Assert(pmState == PM_STARTUP);
> > +
> > + /*
> > + * Go to shutdown mode if a shutdown request was pending.
> > + */
> > + if (Shutdown > NoShutdown)
> > + {
> > + pmState = PM_WAIT_BACKENDS;
> > + /* PostmasterStateMachine logic does the rest */
> > + }
> > + else
> > + {
> > + /*
> > + * Startup process has entered recovery
> > + */
> > + pmState = PM_RECOVERY;
>
>
> Hmm, I smell a race condition here:
>
> 1. Startup process goes into consistent state, and signals postmaster
> 2. Startup process finishes WAL replay and dies
> 3. Postmaster wakes up in reaper(), noting that the startup process
> dies, and goes into PM_RUN mode.
> 4. The above signal handler for postmaster is run, causing an assertion
> failure, or putting postmaster back into PM_RECOVERY mode if assertions
> are disabled.
>
> Highly unlikely in practice, given how much code needs to run in the
> startup process between signaling the postmaster and exiting, but it
> seems theoretically possible. Do we care, and if we do, how can we fix it?
Might be possible - it does depend on the sequence of actions its true.
Agree not likely to happen, except as the result of another bug.
I'll change it to a test for
if (pmState == PM_STARTUP)pmState = PM_RECOVERY;
The assertion was mainly for documentation, its not protecting anything
critical (IIRC).
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
