Dan Ports <drkp@csail.mit.edu> wrote:
> On Sat, May 21, 2011 at 03:09:12PM -0500, Kevin Grittner wrote:
>> I went back to the example which persuaded me and took another
>> look. On review I see that this didn't prove the point because
>> there was a dangerous structure with T1 as a pivot which should
>> have caused SSI to break the cycle. Since it didn't, either I
>> got careless in my testing methodology (which I will recheck when
>> I get back to Wisconsin) or there was a bug -- but either way,
>> this example can't prove that the predicate locks need to follow
>> the row to new versions.
>
> I'm still working through the more general question, but I wanted
> to see what was going on with this example. It appears there's a
> bug, because this doesn't cause a rollback without the version
> linking.
>
> Specifically, the problem is a missing check in
> OnConflict_CheckForSerializationFailure. We check whether the
> conflict has caused the writer to become a pivot, but only if
> neither the reader or writer is committed. Why is that last
> condition there?
Because Fekete et al proved that the pivot doesn't cause an anomaly
unless the transaction read by the pivot commits before the pivot or
the transaction reading the pivot. The problem has to be somewhere
that fails to detect the T1 pivot.
> In this case, the reader (T4) has committed but the writer (T1)
> hasn't.
The T4 commit-first makes this safe. Everything should be OK until
the session 1 activity at the end, which makes T1 a pivot with T2
committing first. I believe we should get the error on this
statement:
update t set txt = 'a' where id = 1;
I was too wiped out from travel to look at it last night, and can't
spend any time on it during business hours today, but after 18:00
CDT today this has my attention.
-Kevin
