Re: Overhead cost of Serializable Snapshot Isolation

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Florian Pflug <fgp(at)phlo(dot)org>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Greg Sabino Mullane <greg(at)turnstep(dot)com>
Subject: Re: Overhead cost of Serializable Snapshot Isolation
Date: 2011-10-12 21:22:59
Message-ID: CA+U5nMLavEHJEYREL=prUA7N0Bczq8Dg1yFsSGfwq44xNgTF6A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 12, 2011 at 1:44 PM, Florian Pflug <fgp(at)phlo(dot)org> wrote:
> On Oct11, 2011, at 23:35 , Simon Riggs wrote:
>> On Tue, Oct 11, 2011 at 10:30 PM, Florian Pflug <fgp(at)phlo(dot)org> wrote:
>>
>>> That experience has taught me that backwards compatibility, while very
>>> important in a lot of cases, has the potential to do just as much harm
>>> if overdone.
>>
>> Agreed. Does my suggestion represent overdoing it? I ask for balance,
>> not an extreme.
>
> It's my belief that an "off" switch for true serializability is overdoing
> it, yes.
>
> With such a switch, every application that relies on true serializability
> for
> correctness would be prone to silent data corruption should the switch ever
> get set to "off" accidentally.
>
> Without such a switch, OTOH, all that will happen are a few more aborts due
> to
> serialization errors in application who request SERIALIZABLE when they
> really
> only need REPEATABLE READ. Which, in the worst case, is a performance issue,
> but never an issue of correctness.

That's a good argument and I accept it.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-10-12 21:31:35 Re: ts_rank
Previous Message Tom Lane 2011-10-12 21:15:50 Re: ALTER EXTENSION .. ADD/DROP weirdness