Re: Serializable Snapshot Isolation

On 15/09/10 00:49, Kevin Grittner wrote:
> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> A short description of how the predicate locks help to implement
>> serializable mode would be nice too. I haven't read Cahill's
>> papers, and I'm left wondering what the RW conflicts and
>> dependencies are, when you're supposed to grab predicate locks
>> etc.
>
> Again -- why be stingy? Given a more complete README file, how
> about something like?:

Well, if it's explained in the readme, that's probably enough.

> /*
> * A rw-conflict occurs when a read by one serializable transaction
> * does not see the write of a concurrent serializable transaction
> * when that write would have been visible had the writing
> * transaction committed before the start of the reading
> * transaction. When the write occurs first, the read can detect
> * this conflict by examining the MVCC information. When the read
> * occurs first, it must record this somewhere so that writes can
> * check for a conflict. Predicate locks are used for this.
> * Detection of such a conflict does not cause blocking, and does
> * not, in itself, cause a transaction rollback.
> *
> * Transaction rollback is required when one transaction (called a
> * "pivot") has a rw-conflict *in* (a concurrent transaction
> * couldn't see its write) as well as *out* (it couldn't see the
> * write of another transaction). In addition, the transaction on
> * the "out" side of the pivot must commit first, and if the
> * transaction on the "in" side of the pivot is read-only, it must
> * acquire its snapshot after the successful commit of the
> * transaction on the "out" side of the pivot.
> */
>
> Would something like that have helped?

Yes. An examples would be very nice too, that description alone is
pretty hard to grasp. Having read the Wiki page, and the slides from
your presentation at pg east 2010, I think understand it now.

Now that I understand what the predicate locks are for, I'm now trying
to get my head around all the data structures in predicate.c. The
functions are well commented, but an overview at the top of the file of
all the hash tables and other data structures would be nice. What is
stored in each, when are they updated, etc.

I've been meaning to look at this patch for some time, but now I'm
actually glad I haven't because I'm now getting a virgin point of view
on the code, seeing the problems that anyone who's not familiar with the
approach will run into. :-)

BTW, does the patch handle prepared transactions yet? It introduces a
call to PreCommit_CheckForSerializationFailure() in CommitTransaction, I
think you'll need that in PrepareTransaction as well.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com