Re: An example of bugs for Hot Standby

On Wed, 2010-01-20 at 06:14 +0100, Andres Freund wrote:
> > 
> > Full resolution patch attached for Startup process waits on buffer pins.
> > 
> > Startup process sets SIGALRM when waiting on a buffer pin. If woken by
> > alarm we send SIGUSR1 to all backends requesting that they check to see
> > if they are blocking Startup process. If so, they throw ERROR/FATAL as
> > for other conflict resolutions. Deadlock stop gap removed.
> > max_standby_delay = -1 option removed to prevent deadlock.

> Wouldnt it be more foolproof to also loop around sending the FATAL? Not that 
> its likely but...

More foolproof and much less accurate. The Startup process doesn't know
who is holding the buffer pin that blocks it, so it could not target a
FATAL.

> From HoldingBufferPinThatDelaysRecovery youre calling 
> GetStartupBufferPinWaitBufId - that sounds a bit dangerous because that one is 
> acquiring a spinlock which can also get taken at other places. Its not the 
> most likely scenario, but it would certainly be annoying to debug.

Spinlock. It isn't held for long in any situation. What problem do you
foresee?

> Is there any supported platform with sizeof(sig_atomic_t) <4 - I would doubt 
> so? If not the locking in GetStartupBufferPinWaitBufId and 
> SetStartupBufferPinWaitBufId shouldnt be needed? 

I prefer spinlocking.

> Same issue issue (and more likely to trigger) exists with CheckStandbyTimeout-
> >SendRecoveryConflictWithBufferPin->CancelDBBackends

I don't see an issue.

-- Simon Riggs           www.2ndQuadrant.com