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

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: <drkp(at)csail(dot)mit(dot)edu>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SSI predicate locking on heap -- tuple or row?
Date: 2011-05-26 19:03:48
Message-ID: 4DDE5DC4020000250003DD85@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:

> Could you explain in the README, why it is safe to only take the
> lock on the visible row version, please?

Sure. I actually intended to do this last night but ran out of
steam and posted what I had, planning on following up with that.

The place it seemed to fit best was in the "Innovations" section,
since the SSI papers and their prototype implementations seemed
oriented toward "rows" -- certainly the SIREAD locks were at the row
level, versus a row version level.

Since this doesn't touch any of the files in yesterday's patch, and
it seems entirely within the realm of possibility that people will
want to argue about how best to document this more than the actual
fix, I'm posting it as a separate patch -- README-SSI only.

I mostly just copied from Dan's posted proof verbatim.

-Kevin

Attachment Content-Type Size
ssi-readme-tuple-lock.patch text/plain 3.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2011-05-26 19:26:39 Re: inconvenient compression options in pg_basebackup
Previous Message Stephen Frost 2011-05-26 18:57:43 Re: Pre-alloc ListCell's optimization