On Tue, Oct 11, 2011 at 6:44 PM, Kevin Grittner <kevin.gritt...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
