Simon Riggs wrote:
> On Tue, Oct 11, 2011 at 6:44 PM, Kevin Grittner
> <Kevin.Grittner@wicourts.gov> wrote:
>
> >> If you alter the default_transaction_isolation then you will break
> >> applications like this, so it is not a valid way to turn off SSI.
> >
> > I don't follow you here. ?What would break? ?In what fashion? ?Since
> > the standard allows any isolation level to provide more strict
> > transaction isolation than required, it would be conforming to
> > *only* support serializable transactions, regardless of the level
> > requested. ?Not a good idea for some workloads from a performance
> > perspective, but it would be conforming, and any application which
> > doesn't work correctly with that is not written to the standard.
>
> If the normal default_transaction_isolation = read committed and all
> transactions that require serializable are explicitly marked in the
> application then there is no way to turn off SSI without altering the
> application. That is not acceptable, since it causes changes in
> application behaviour and possibly also performance issues.
>
> We should provide a mechanism to allow people to upgrade to 9.1+
> without needing to change the meaning and/or performance of their
> apps.
>
> I strongly support the development of SSI, but I don't support
> application breakage. We can have SSI without breaking anything for
> people that can't or don't want to use it.
The problem is that all the switches needed to allow for "no application
breakage" makes configuration of the server and source code more
complicated.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
