On Fri, 2009-01-23 at 21:30 +0200, Heikki Linnakangas wrote: > 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. > > 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.
That makes it easier, because it is either not set, or it is set and does not need to be reset as new conflict LSNs appear. I can see a simple scheme emerging, which I will detail tomorrow morning. -- 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
