Re: Update on true serializable techniques in MVCC - Mailing list pgsql-hackers

From Albe Laurenz
Subject Re: Update on true serializable techniques in MVCC
Date
Msg-id D960CB61B694CF459DCFB4B0128514C2039380CD@exadv11.host.magwien.gv.at
Whole thread Raw
In response to Update on true serializable techniques in MVCC  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses 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>)
List 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 by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: Range types
Next
From: Heikki Linnakangas
Date:
Subject: Re: Streaming replication and non-blocking I/O