From: | Kevin Grittner <kgrittn(at)gmail(dot)com> |
---|---|
To: | kuntalghosh(dot)2007(at)gmail(dot)com |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, hlinnaka(at)iki(dot)fi, Jeff Davis <pgsql(at)j-davis(dot)com>, joe(dot)conway(at)crunchydata(dot)com |
Subject: | Re: In-place updates and serializable transactions |
Date: | 2018-11-14 21:27:24 |
Message-ID: | CACjxUsM+FQebmUnXBYYQEGMjeN=10qV6Dy_Do4pC3ijsGMuB6g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Nov 13, 2018 at 10:45 PM Kuntal Ghosh
<kuntalghosh(dot)2007(at)gmail(dot)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/
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2018-11-14 21:36:49 | Re: Refactoring the checkpointer's fsync request queue |
Previous Message | David Rowley | 2018-11-14 20:48:33 | Re: Speeding up INSERTs and UPDATEs to partitioned tables |