Re: Overhead cost of Serializable Snapshot Isolation

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Simon Riggs" <simon(at)2ndQuadrant(dot)com>
Cc: "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-11 20:37:38
Message-ID: 4E9462C20200002500041E22@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)com> wrote:
> Greg Sabino Mullane <greg(at)endpoint(dot)com> wrote:

>> Eh? It has an off switch: repeatable read.
>
> You mean: if we recode the application and retest it, we can get
> it to work same way as it used to.
>
> To most people that is the same thing as "it doesn't work with
> this release", ask any application vendor.
>
> There is no off switch and there should be.

This was discussed at some length, and nobody seemed to favor a
behavior-changing GUC. One example of such a thread is here:

http://archives.postgresql.org/pgsql-hackers/2009-05/msg01165.php

It came up at least a couple other times, and the outcome was always
the same -- after discussion, nobody was in favor of a GUC to make
the semantics of these statement variable. I'm sorry if you missed
those discussions. It would certainly be a trivial change to
implement; the problem is convincing others that it's a good idea.

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-10-11 20:39:03 Re: SET variable - Permission issues
Previous Message Simon Riggs 2011-10-11 20:37:24 Re: unite recovery.conf and postgresql.conf