Re: SSI predicate locking on heap -- tuple or row?

Robert Haas <robertmhaas@gmail.com> wrote:
> The point I was driving at is - in what way will that affect the
> behavior of subsequent operations?
You haven't answered why you think it should matter for OID or for
write conflict on READ COMMITTED but not here.  The logical concept
of a row which is modified is a meaningful one regardless of any
particular database's internal implementation.  The fact that the
proofs of SSI techniques use row-oriented terminology shouldn't be
simply ignored.  The fact that the two prototype implementations in
the papers on the topic used databases with "update in place with a
rollback log" for their MVCC implementations, and took their
predicate locks on the "in place" row, reinforce that.
No flaws jumped out at me in a review of the longer logical argument
after sleeping on it, Robert said it looked good to him, and Dan
said he would look at it soon.  If it looks good to Dan, and nobody
else pokes a hole in the logic, I'll have enough confidence to
proceed.
-Kevin