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

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <drkp(at)csail(dot)mit(dot)edu>,"Aidan Van Dyk" <aidan(at)highrise(dot)ca>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SSI predicate locking on heap -- tuple or row?
Date: 2011-05-23 15:38:12
Message-ID: 4DDA3914020000250003DB28@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2011-05-23 16:42:34 Identifying no-op length coercions
Previous Message David Fetter 2011-05-23 15:03:47 Re: Do you recommend 8.4 or 9.0 for basic usage?