Skip site navigation (1) Skip section navigation (2)

Re: User-facing aspects of serializable transactions

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: User-facing aspects of serializable transactions
Date: 2009-05-28 00:52:05
Message-ID: 1243471925.24838.196.camel@monkey-cat.sm.truviso.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, 2009-05-27 at 20:38 -0400, Tom Lane wrote:
> A lesson that I think we've learned the hard way over the past few years
> is that GUCs are fine for controlling performance issues, but you expose
> yourself to all sorts of risks if you make fundamental semantics vary
> depending on a GUC.

I agree with the philosophy here.

> Putting those two thoughts together, I would say that the right thing
> is
> 
> * SET TRANSACTION ISOLATION LEVEL SERIALIZABLE should mean what the spec
> says.
> 
> * SET TRANSACTION ISOLATION LEVEL something-else should provide our
> current snapshot-driven behavior.  I don't have a strong feeling about
> whether "something-else" should be spelled REPEATABLE READ or SNAPSHOT,
> but lean slightly to the latter.
> 
> * Anything else you want to control should be a GUC, as long as it
> doesn't affect any correctness properties.

But that still leaves out another behavior which avoids some of the
serialization anomalies currently possible, but still does not guarantee
true serializability (that is: implementation of the paper's technique
sans predicate locking). Is that behavior useful enough to include?

Just trying to come up with a name for that might be challenging.

Regards,
	Jeff Davis


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-05-28 00:55:18
Subject: Re: User-facing aspects of serializable transactions
Previous:From: Mark WongDate: 2009-05-28 00:51:28
Subject: Re: survey of WAL blocksize changes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group