On Fri, May 8, 2009 at 4:12 PM, Greg Stark <st...@enterprisedb.com> wrote: > On Fri, May 8, 2009 at 3:49 PM, Kevin Grittner > <kevin.gritt...@wicourts.gov> wrote: >> Greg Stark <st...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
