Re: Update on true serializable techniques in MVCC

Поиск
Список
Период
Сортировка
От Albe Laurenz
Тема Re: Update on true serializable techniques in MVCC
Дата
Msg-id D960CB61B694CF459DCFB4B0128514C2039380CD@exadv11.host.magwien.gv.at
обсуждение исходный текст
Ответ на Update on true serializable techniques in MVCC  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: Update on true serializable techniques in MVCC  (Nicolas Barbier <nicolas.barbier@gmail.com>)
Re: Update on true serializable techniques in MVCC  (Florian Weimer <fweimer@bfk.de>)
Re: Update on true serializable techniques in MVCC  (Robert Haas <robertmhaas@gmail.com>)
Re: Update on true serializable techniques in MVCC  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список pgsql-hackers
Kevin Grittner wrote:
> Just to make those who care aware of it, here is Michael Cahill's
> Doctoral Thesis based on implementing Serializable Snapshot
> Isolation in InnoDB using a refined version of the techniques
> previously used in the Berkley DB (and previously discussed on this
> list):
>
> http://hdl.handle.net/2123/5353
>
> Seriously, this post is just for the benefit of those who may be
> interested in following these developments -- I don't have the
> inclination or energy for another round of debate on the topic just
> now.  :-/

I understand that, and thank you for the information.
Although it may have seemed that I was out to shoot the idea down,
I am interested in the topic. I guess my way of understanding something
is trying to find holes in it...

I read into the text, and I was particularly interested how he solved
the problem of phantom reads.

Quote:  The problem [of phantom reads] was identified in (Eswaran et al., 1976),  but the general purpose "predicate
locking"solution suggested there  has not been widely adopted because of the difficulty in testing mutual
satisfiabilityof predicates. 
  Instead, locking DBMS implementations commonly use algorithms based on  "next-key locking". In these, a range of key
spaceis protected against  concurrent insertion or deletion by acquiring a shared lock on the next  row in order, as a
scanis made to check whether rows match a predicate.  The scan might be through the data records or through an index. 
  Inserts and deletes follow the same protocol, obtaining an exclusive  lock on the row after the one being inserted or
deleted.The result  of this locking protocol is that a range scan prevents concurrent  inserts or delete within the
rangeof the scan, and vice versa. 

That sounds like it should actually work.

Yours,
Laurenz Albe


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Re: Range types
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Streaming replication and non-blocking I/O