Re: User-facing aspects of serializable transactions

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