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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
