Re: Serializable Isolation without blocking

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Markus Wanner <markus(at)bluegap(dot)ch>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, nicolas(dot)barbier(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org, laurenz(dot)albe(at)wien(dot)gv(dot)at
Subject: Re: Serializable Isolation without blocking
Date: 2010-01-07 20:37:45
Message-ID: 1262896665.5908.390.camel@monkey-cat.sm.truviso.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 2010-01-07 at 15:02 -0500, Robert Haas wrote:
> > I think we're still talking past the issue. Predicate locks are not
> > row level, nor page level, nor table level.
>
> They're not? They're just floating out in space somewhere? There are
> several possible ways to implement predicate locks, but every possible
> method I can think of involves attaching them at one of those places.

Consider an exclusion constraint, which is a kind of predicate lock. You
could say that the lock is in the index (now) -- but my first
implementation used a shared memory structure instead, so it's clearly
not required to exist in the index. You could also say that the lock is
really attached to the table, because there are catalog entries
connected to the table that express the constraint -- but I think that's
splitting hairs.

What Greg is saying (as I understand it) is that the lock conflicts with
tuples that don't even exist yet. We can tack them on to any structure
that's convenient, of course. But just because you want to implement
them by locking a few index pages (assuming there is an index) doesn't
mean we should reject Greg's line of thinking.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2010-01-07 20:42:02 Re: RFC: PostgreSQL Add-On Network
Previous Message Dave Page 2010-01-07 20:36:38 Re: RFC: PostgreSQL Add-On Network