Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> On Tue, 30 Sep 2003, Tom Lane wrote:
>> ... Note that this implementation
>> means that case 3 will not throw errors, because such rows will be
>> ignored by the scan. I think this is an okay tradeoff for getting the
>> other cases right.
> It's probably better than the current situation anyway. I think that it'd
> be revisitable if someone wanted to bring it up later.
It might be possible to hack things so that the scans will return
tuples that are visible according to either of two snapshots. However
this would be considerably less localized a change than what I had in
mind, and it still doesn't really make things watertight. (For example,
imagine that a conflicting tuple is created by transaction B and then
deleted by transaction C, all while our own serializable transaction is
running. Arguably we should throw an error, but there's no way to find
that tuple using either our transaction-start or our transaction-end
snapshot.)
> I'd have figured that this would be a bigger deal to implement cleanly,
> but if it isn't, then it sounds good. I'm a little worried because
> there's been talk of beta and this going in now for fear of breaking
> something worse than it already is, but if you think that it's safe
> enough.
I think I can implement it and it will act as stated in my proposal.
Whether people like the proposed behavior is the big question in my
mind. (Hope Marc gets the mail lists back online soon ...)
regards, tom lane