On Sun, Jan 16, 2005 at 07:28:07PM -0600, Jim C. Nasby wrote: > On Sun, Jan 16, 2005 at 08:01:36PM -0500, Tom Lane wrote: > > "Jim C. Nasby" <[EMAIL PROTECTED]> writes: > > > Wouldn't the original proposal that had a state machine handle this? > > > IIRC the original idea was: > > > > > new tuple -> known good -> possibly dead -> known dead > > > > Only if you disallow the transition from possibly dead back to known > > good, which strikes me as a rather large disadvantage. Failed UPDATEs > > aren't so uncommon that it's okay to have one permanently disable the > > optimization. > > Actually, I guess I wasn't understanding the problem to begin with. > You'd never go from new tuple to known good while the transaction that > created the tuple was in-flight, right? If that's the case, I'm not sure > where there's a race condition. You can't delete a tuple that hasn't > been committed, right?
Er, nevermind, I thought about it and realized the issue. What changes when a delete is done on a tuple? It seems that's the key... if a tuple has been marked as possibly being expired/deleted, don't allow it to go into known_good unless you can verify that the transaction that marked it as potentially deleted was rolled back. -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])