Re: Serializable Snapshot Isolation

On 15/09/10 00:49, Kevin Grittner wrote:
> Heikki Linnakangas<heikki.linnakangas@enterprisedb.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