On Fri, May 8, 2009 at 4:12 PM, Greg Stark <stark@enterprisedb.com> wrote:
> On Fri, May 8, 2009 at 3:49 PM, Kevin Grittner
> <Kevin.Grittner@wicourts.gov> wrote:
>> Greg Stark <stark@enterprisedb.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.
Argh, sorry, as soon as I hit send I realized this is wrong. Writers
already need to insert into every index, so that's not a problem. The
problem is if readers need to see other reader locks. If that's not
true then I guess I'm all wet and I will wait until I read the paper.
--
greg
