Re: In-place updates and serializable transactions

On Tue, Nov 13, 2018 at 10:45 PM Kuntal Ghosh
<kuntalghosh.2007@gmail.com> wrote:

> Currently, we're working on the serializable implementations for
> zheap.

Great!

> If transaction T1 reads a row version (thus acquiring a predicate lock
> on it) and a second transaction T2 updates that row version (thus
> creating a rw-conflict graph edge from T1 to T2), must a third
> transaction T3 which re-updates the new version of the row also have a
> rw-conflict in from T1 to prevent anomalies?  In other words,  does it
> matter whether we recognize the edge T1 --rw--> T3?

No.  Keep in mind that extensive study has shown that snapshot
isolation can only be non-serializable if there is a cycle in the
apparent order of execution and that this can only occur if there is a
"dangerous structure" of two adjacent read-write antidependencies
(a/k/a read-write dependencies, a/k/a rw-conflicts) *AND* the
transaction you identify as T3 in that structure *IS THE FIRST
TRANSACTION IN THE CYCLE TO COMMIT*.  Looking at the implied T1/T3
relationship and looking for a T4 to complete the structure is not
necessary, because there are proofs that three *ADJACENT* transactions
are necessary for a serialization anomaly to be seen.

-- 
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/