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.com
PostgreSQL Training, Services and Support