This was probably covered in lecture, but if both p2 and p1 had c in their write set at the time of committing transaction 1, why did p2 not have to restart t3? Does this have to do with t3 having no knowledge of what's happening in t1 until it commits? I thought we have conflicts in both cases where a committing transaction writes to a variable to be read by another transaction or 2 transactions write to the same variable and 1 tries to commit?

@tigerpanda I believe it is indeed a write-write conflict, but in lazy optimistic TM systems, we can let it pass without affecting correctness of TM:

When T1 commits, we compare its write set (A, C) to the read & write sets of other pending transactions. If T3's read set contains A or C (when T1 commits), then it will have to abort and retry, because we want T1 to happen before T3 and T3 shouldn't read stale values of A or C that haven't been updated. Here, T3's read set is fine, but write set contains C. It is still correct if T3 doesn't abort, because T3 is writing to C without reading its old value first. What T1 is going to write to C does not affect T3's behavior, and we can still serialize the transaction orders as T1 then T3. Plus write is lazy, so T3's updated value of C won't be visible to other processors until T3 commits.

I'm wondering if the W C, 5 of P2, after the row B T3, should be W C, 4..

I was also a little confused about the W C part but how I thought about it is that the writes to C don't actually "exist", since they are performed on a buffer in lazy versioning. Hence, if other processors try to read C, they would get the version that exists within their code.

The final value of C is deterministic in this case, is there a case when it's not?

Please correct me if I'm wrong but if I understand this example properly, in lazy optimistic systems, read-write conflicts lead to aborts on commit but write-write conflicts do not cause aborts.