On Mon, May 23, 2011 at 2:26 AM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> I don't see that -- it could be correct because of the conceptual
> difference between an UPDATE and a DELETE/INSERT pair.
>
>> In other words, if SSI needs to be more rigorous in the UPDATE
>> case, it can only be because snapshot isolation is less rigorous in
>> that case, and the additional rigor that SSI must apply there must
>> be exactly equal to whatever snapshot isolation isn't picking up
>> (as compared with the DELETE/INSERT case).
>>
>> Does that make any sense? It seems logical to me, but IJWH.
>
> I've always loved logic, but one of the most intriguing aspects is
> identifying the unproven assumptions in an argument. You have a
> built-in premise that there is no significant difference between an
> UPDATE and a DELETE/INSERT pair, in which case the logic is flawless
> which is leading you to the conclusion that a lock on the visible
> tuple is enough. I'm not confident in that premise, so the simple
> argument doesn't persuade me.
I *think* (but am in no means familiar with SSI, or an expert on the
problems it's trying to solve), that Robert was only arguing that SSI
is only "relevant" to solve problems that the non SSI wouldn't catch.
And the "sameness" of UPDATE vs DELETE+INSERT, is simply because if
you can only see the data as it was *completely before* or *completely
after* a transaction (not as it was after the delete, before the
insert), then to you, it doesn't matter if the transaction did an
UPDATE, or an DELETE+INSERT. All you see is either $OLDROW, or
$NEWROW, depending if you see it before, or after, not the
transformation from $OLDROW to $NEWROW.
So, if SSI conflicts something on the UPDATE case, it would necessrily
have to conflict the DELETE+INSERT case as well, and vice-versa.
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
