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
> * SET TRANSACTION ISOLATION LEVEL SERIALIZABLE should mean what the spec
> * 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.
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2009-05-28 00:55:18|
|Subject: Re: User-facing aspects of serializable transactions |
|Previous:||From: Mark Wong||Date: 2009-05-28 00:51:28|
|Subject: Re: survey of WAL blocksize changes|