"Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at> wrote:
> Kevin Grittner wrote:
>> I do think you misunderstood. If there are two concurrent
>> executions and each reads one row, there will be an SIREAD lock for
>> each of those rows. As an example, let's say that one of them (T0)
>> updates its row and does its count, finds everything looks fine,
>> and commits. In reading the row the other transaction (T1)
>> modified it sets the T0.outConflict flag to true and the
>> T1.inConflict flag to true.
>
> Where does T0 read the row that T1 modified?
As I said in the original post, I think we would need to track SIREAD
locks in the structures which back the pg_locks view.
>> blocking occurs. Now T1 updates its row.
>
> Wait a minute, I am confused. I thought T1 had already modified the
> row before T0 committed? Or is "modify" not the update?
There are so many sequences that I didn't think it was worthwhile to
step through them all, I did say "As an example, let's say that one of
them (T0) updates its row and does its count, finds everything looks
fine, and commits." If you want to work through the case where they
both UPDATE their rows before either commits, OK; it's not that
different. Things are OK as far as the first select of a modified row
by the other transaction; you record inConflict for one and
outConflict for the other. At the point where it goes both
directions, it is clear that there is a dangerous interaction and one
or the other is rolled back.
> Where does T1 select rows that were modified by T0? It selects only
> one row, the one it modified itself, right?
You have to select it to know whether to count it, right?
> You see, there must be something fundamental I am getting wrong.
It is such a radical departure from traditional blocking approaches,
that it can be hard to get your head around it. :)
-Kevin