Re: Exposing the Xact commit order to the user

Поиск
Список
Период
Сортировка
От Dan Ports
Тема Re: Exposing the Xact commit order to the user
Дата
Msg-id 20100525184844.GD53044@csail.mit.edu
обсуждение исходный текст
Ответ на Re: Exposing the Xact commit order to the user  (Florian Pflug <fgp@phlo.org>)
Ответы Re: Exposing the Xact commit order to the user  (Florian Pflug <fgp@phlo.org>)
Список 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 по дате отправления:

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: Re: Exposing the Xact commit order to the user
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: Exposing the Xact commit order to the user