Re: SSI predicate locking on heap -- tuple or row? - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: SSI predicate locking on heap -- tuple or row?
Date
Msg-id 4DDA3914020000250003DB28@gw.wicourts.gov
Whole thread Raw
In response to Re: SSI predicate locking on heap -- tuple or row?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: Do you recommend 8.4 or 9.0 for basic usage?
Next
From: Noah Misch
Date:
Subject: Identifying no-op length coercions