Re: Hot standby, conflict resolution

On Fri, 2009-01-23 at 21:30 +0200, Heikki Linnakangas wrote:

> >> Correct me if I'm wrong, but I thought the idea of this new conflict 
> >> resolution was that the startup process doesn't need to wait for the 
> >> target backend to die. Instead, the target backend knows to commit 
> >> suicide if it stumbles into a buffer that's been modified in a 
> >> conflicting way. Looking at ResolveRecoveryConflictWithVirtualXIDs, it 
> >> looks like we still wait.
> > 
> > err, no, that's just an oversight, not intentional.
> 
> Ok, then I think we have a little race condition. The startup process 
> doesn't get any reply indicating that the target backend has processed 
> the SIGINT and set the cached conflict LSN. The target backend might 
> move ahead using the old LSN for a little while, even though the startup 
> process has already gone ahead and replayed a vacuum record.

Hah! You had me either way. Very neat :-)

I'll think some more and reply, but not tonight.

> Another tiny issue is that it looks like a new conflict LSN always 
> overwrites the old one. But you should always use the oldest conflicted 
> LSN in the checks, not the newest.

OK

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support