On May 25, 2010, at 20:48 , Dan Ports wrote:
> 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.

Yeah, as long as you just walk by without looking, the database is happy ;-)

>> Btw, I still don't get how this follows from the Cahill paper. For a 
>> transaction to lie on a dangerous circle, it needs incoming and outgoing 
>> edges in the conflict graph, right? But I'd have though that conflicts are 
>> always between a reader and 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.

Hm, but for there to be an actual problem (and not a false positive), an actual 
dangerous circle has to exist in the dependency graph. The existence of a 
dangerous structure is just a necessary (but not sufficient) and easily 
checked-for condition for that, right? Now, if a read-only transaction only 
ever has outgoing edges, it cannot be part of a (dangerous or not) circle, and 
hence any dangerous structure it is part of is a false positive.

I guess my line of reasoning is flawed somehow, but I cannot figure out why...

best regards,
Florian Pflug


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to