Re: Serializable Isolation without blocking
От | Greg Stark |
---|---|
Тема | Re: Serializable Isolation without blocking |
Дата | |
Msg-id | 4136ffa0905080815n20fc047av91b93a9c217a041a@mail.gmail.com обсуждение исходный текст |
Ответ на | Serializable Isolation without blocking ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: Serializable Isolation without blocking
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: