Jeff Davis <pgsql@j-davis.com> wrote:
>> I'm torn between thinking it would be good to spell it that way
>> and thinking that we should have
>> "serializable_isolation_implementation" GUC (or something to that
>> effect) which maps to an enumeration containing "snapshot" and
>> "ssi". Opinions welcome, since I've put that GUC at the top of
>> my implementation list. :-)
>
> If there are different semantics, we shouldn't just call it an
> implementation detail. Particularly when the old behavior violates
> the standard (at least the newest version, I think).
That is a point in favor or your spelling, for sure. I guess I was
still trying to leave the door at least ajar for a parallel S2PL
implementation, but perhaps that belongs in the "we'll cross that
bridge when we come to it" category. (Just so we don't burn that
bridge before we get there....)
>> It really depends on application code we might
>> break, which is hard to determine.
>
> Well, hopefully it doesn't break anything. Applications asking for
> SERIALIZABLE should already be expecting serialization errors. Did
> you have something else in mind?
It seems that some users like to assume that most queries can't get
serialization errors and try to identify those which can and handle
the errors specifically in those cases. In my experience that is
not wise, especially if you are trying for portable code, but it
seems to have worked reasonably well for some users historically, so
we would need a very good reason to break it for them. I'd suggest
we plan on leaving the option indefinitely, until such time as
someone feels compelled for some reason to address the issue.
Granted, the fix is pretty simple, but if they have their sets of
transaction isolation level scattered around their code, "simple"
wouldn't necessarily mean "quick and easy."
-Kevin
