"Jim C. Nasby" <decibel@decibel.org> writes:
> 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?
By definition, not.
> 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?
The originating transaction could itself delete the tuple, but no one
else could see it yet to do that. This means that you'd have to allow
a transition directly from new tuple to possibly dead. (In the absence
of subtransactions this could be optimized into a transition directly
to known dead, but now that we have subtransactions I don't think we
can do that.)
However, the race condition comes in when someone wants to delete the
row at about the same time as someone else is trying to mark it known
good, ie, sometime *after* the originating transaction committed.
This is definitely a possible situation.
regards, tom lane