Re: Overhead cost of Serializable Snapshot Isolation

From: Florian Pflug <fgp(at)phlo(dot)org>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
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 12:44:29
Message-ID: D573F78C-19E3-44A6-95D4-A30E6CFCE83A@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

best regards,
Florian Pflug

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-10-12 12:46:38 Re: [v9.2] DROP statement reworks
Previous Message Kohei KaiGai 2011-10-12 12:07:53 Re: [v9.2] DROP statement reworks