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.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
