Re: Update on true serializable techniques in MVCC

From: "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "Kevin Grittner *EXTERN*" <Kevin(dot)Grittner(at)wicourts(dot)gov>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Update on true serializable techniques in MVCC
Date: 2009-12-16 09:52:34
Message-ID: D960CB61B694CF459DCFB4B0128514C2039380CD@exadv11.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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
satisfiability of predicates.

Instead, locking DBMS implementations commonly use algorithms based on
"next-key locking". In these, a range of key space is protected against
concurrent insertion or deletion by acquiring a shared lock on the next
row in order, as a scan is 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 range of the scan, and vice versa.

That sounds like it should actually work.

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2009-12-16 09:53:49 Re: Streaming replication and non-blocking I/O
Previous Message Dimitri Fontaine 2009-12-16 09:36:15 Re: Range types