Re: Overhead cost of Serializable Snapshot Isolation

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)endpoint(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Overhead cost of Serializable Snapshot Isolation
Date: 2011-10-11 20:21:11
Message-ID: CA+U5nMJRb7sGVzsQsvSv+8Wiv24XVV4Xe1MYbZ4HqzEBe00y0w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 11, 2011 at 6:44 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2011-10-11 20:21:15 Re: unite recovery.conf and postgresql.conf
Previous Message Tom Lane 2011-10-11 20:19:35 Re: Dumping roles improvements?