Re: Serializable Isolation without blocking

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Markus Wanner <markus(at)bluegap(dot)ch>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, nicolas(dot)barbier(at)gmail(dot)com, robertmhaas(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 19:40:01
Message-ID: 407d949e1001071140w26ff7d0dt4fa67b5b7ca77958@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 7, 2010 at 11:08 AM, Markus Wanner <markus(at)bluegap(dot)ch> wrote:
> Row level locks are very fine grained, but those are spilled to disk in
> its current implementation. So those are an even worse fit for the needs
> of SIREAD.
>

I think we're still talking past the issue. Predicate locks are not
row level, nor page level, nor table level. They're locks on
predicates. Ie, you have to lock against values which aren't actually
currently in the table at all. You need to be able to detect a
conflict between a transaction which read rows "WHERE i BETWEEN 1 AND
10" and one which tries to insert a row with i=1 even if the first
transaction didn't see any rows with i=1 (or indeed even if the first
transaction found no rows at all).

That's the hard part. How do you represent such a lock in a way that I
can efficiently find it and check for the conflict when it comes time
for me to do my insert.

And how do you do that without tying the implementation to specific
details of how our planner, table scans, and index access methods
work?

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-01-07 19:40:49 Re: Hot Standy introduced problem with query cancel behavior
Previous Message Kevin Grittner 2010-01-07 19:34:38 Re: true serializability and predicate locking