Re: Serializable implementation - Mailing list pgsql-hackers

Jeff Davis <pgsql@j-davis.com> wrote:
> 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.
OK.  I actually thought this might be useful for testing, since we
could run a test with SI and SSI without changing any code in the
test -- change the conf file, reload, and run again.  I guess,
though, that it shouldn't be too bad to find some other way to
control that, and adding a GUC for development that we rip out at
the end would be a bit silly.
I guess the question is whether we need the GUC to support people
who are asking for serializable transaction isolation but wouldn't
be prepared to deal with an increase in serialization failures from
actually *getting* serializable isolation.
>>  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.
Agreed.  Snapshot should clearly continue to map to REPEATABLE READ,
so I see no reason to invent a nonstandard alias for it.
> 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.
Now you're being much more optimistic than I.  I think that a year
from now we'll be working to get performance to an acceptable range,
and at the point where I feel it's usable for us there will still be
months of work to address concerns which will be raised only when it
seems that an actual commit might be imminent.  (I mean, does that
ever *not* happen on a big patch?)  That puts this, probably in the
third major release after 8.4, whatever number that gets.
Other than the optimistic release number, however, I think your
point is on target.  It could at least help justify making fully
serializable transactions the default for the GUC, and maybe justify
not even having the GUC.
> 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).
I agree that it would break no promises; but it could break existing
applications.  It would only break applications which depended on
certain assumptions -- namely that the serializable level would
specifically be snapshot isolation and based on that it would be
possible to analyze all combinations of concurrent transactions and
accurately predict which ones might roll back with a serialization
errors, and it is OK to code specifically for such errors only on
the vulnerable transactions.
The only evidence I've seen that such applications exist is the
pushback from some on this list regarding the unpredictability of
which transactions could roll back on serialization failures -- that
it could happen on transactions for which the programmer didn't
handle it.  I've assumed that this objection was based on some
knowledge that such coding was in production somewhere.  If it is,
we either need the GUC or we rationalize its absence on the basis of
having told people for two years to use REPEATABLE READ if they want
bare snapshot behavior.
Opinions?
-Kevin