On Tue, 30 Sep 2003, Tom Lane wrote:
> 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.)
That's what I was thinking, but that it could be done later if someone
wanted. But you're right that it still wouldn't be a complete solution, I
hadn't thought about that case. :(
> > 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.
I think it's more reasonable than the current behavior or any of
the others we've hit along the way, and we have to pretty much choose
now if we want to change it for 7.4.
> (Hope Marc gets the mail lists back online soon ...)
Yeah, this always seems to happen right around beta time... :)