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
