Re: Serializable implementation - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Serializable implementation
Date
Msg-id 1262917230.5908.606.camel@monkey-cat.sm.truviso.com
Whole thread Raw
In response to Re: Serializable implementation  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Serializable implementation
List pgsql-hackers
On Thu, 2010-01-07 at 21:02 -0500, Robert Haas wrote:
> Hmm.  Why would we use a GUC for this instead of an additional option
> to BEGIN TRANSACTION?

I'm with you. I feel pretty strongly that we should not have
behavior-changing GUCs.

I make an exception for compatibility GUCs where the eventual default
will be the new behavior, the vast majority of users will be using the
new behavior in a release or two, and we just have the GUC to allow
backwards compatibility for a while (and would be willing to potentially
eliminate the GUC in a few releases).

The last thing we want are 103 behavior-changing GUCs that vary widely
in their settings among users.

> BEGIN TRANSACTION ISOLATION LEVEL {READ COMMITTED | SNAPSHOT | SERIALIZABLE}
> 
> With our current levels being the first two of those.
> 
> Or is that a bad idea?

We already have REPEATABLE READ which already has the same semantics as
SNAPSHOT would have, so I don't think we need to introduce a new one.

I think the only thing we need to do is suggest that people start using
REPEATABLE READ if they want snapshot isolation. That will give us more
freedom to change SERIALIZABLE to be true serializability in 8.6.

If we need a GUC that aliases SERIALIZABLE to REPEATABLE READ for
backwards compatibility (after we change SERIALIZABLE) for a short
period of time, that sounds reasonable. Even that may not be necessary
though because it shouldn't really break any promises that we made in
the documentation (that I'm aware of).

Regards,Jeff Davis



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: damage control mode
Next
From: Jeff Davis
Date:
Subject: Re: damage control mode