Re: Serializable Isolation without blocking

From: Greg Stark <stark(at)enterprisedb(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Michael Cahill <mjc(at)it(dot)usyd(dot)edu(dot)au>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Serializable Isolation without blocking
Date: 2009-05-08 15:12:20
Message-ID: 4136ffa0905080812k369554eci7b2e1d8930d2c637@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, May 8, 2009 at 3:49 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Greg Stark <stark(at)enterprisedb(dot)com> wrote:
>
>> Well I don't understand what storing locks in an index can
>> accomplish if other queries might use other indexes or sequential
>> scans to access the records and never see those locks.
>>
>> Or does this method only require that writers discover the locks and
>> therefore only writers can ever fail due to serialization failures
>> they cause?
>
> Well, readers don't need to find the SIREAD locks which readers set.
> Conflicts between writers are handled the same as current PostgreSQL
> techniques.  Readers need to look for write locks, and writers need to
> look for SIREAD locks.

Well this is where I'm failing to follow. If readers need to be sure
they'll find write locks then surely they can't be stored in indexes
without losing any flexibility.

You would need to be sure other readers will look at the same index
you put the lock in -- so you either need to put the lock in every
index, have other readers look in every index, or have a very limited
predictable way of ensuring everyone will use the same index for any
queries where that lock matters.

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2009-05-08 15:15:10 Re: Serializable Isolation without blocking
Previous Message Kevin Grittner 2009-05-08 14:49:17 Re: Serializable Isolation without blocking