Re: Exposing the Xact commit order to the user - Mailing list pgsql-hackers

From Dan Ports
Subject Re: Exposing the Xact commit order to the user
Date
Msg-id 20100525184844.GD53044@csail.mit.edu
Whole thread Raw
In response to Re: Exposing the Xact commit order to the user  (Florian Pflug <fgp@phlo.org>)
Responses Re: Exposing the Xact commit order to the user
List pgsql-hackers
On Tue, May 25, 2010 at 08:35:44PM +0200, Florian Pflug wrote:
> Hm, so in fact SSI sometimes allows the database to be inconsistent, but only as long as nobody tries to observe it?

Yes. Note that even while it's in an inconsistent state, you can still
perform any query that doesn't observe the inconsistency -- hopefully
most queries fall into this category.

> Btw, I still don't get how this follows from the Cahill paper. For a transaction to lie on a dangerous circle, it
needsincoming and outgoing edges in the conflict graph, right? But I'd have though that conflicts are always between a
readerand a writer or between two writers. So how can a read-only transaction have incoming and outgoing edges?
 

Right, the read-only transaction can't have incoming edges, but it can
have outgoing edges. So it can't be the "pivot" itself (the transaction
with both outgoing and incoming edges), but it can cause *another*
transaction to be.

In the example I gave, T3 (the r/o transaction) has an outgoing edge to
T1, because it didn't see T1's concurrent update. T1 already had an
outgoing edge to T2, so adding in this incoming edge from T3 creates
the dangerous structure.

Dan

-- 
Dan R. K. Ports              MIT CSAIL                http://drkp.net/


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Exposing the Xact commit order to the user
Next
From: "Kevin Grittner"
Date:
Subject: Re: Exposing the Xact commit order to the user