Skip site navigation (1) Skip section navigation (2)

Re: User-facing aspects of serializable transactions

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Jeff Davis" <pgsql(at)j-davis(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: User-facing aspects of serializable transactions
Date: 2009-05-27 23:54:31
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Jeff Davis <pgsql(at)j-davis(dot)com> wrote: 
> On Wed, 2009-05-27 at 15:34 -0500, Kevin Grittner wrote:
>> (C)  One or more GUCs will be added to control whether the new
>> behavior is used when serializable transaction isolation is
>> requested or whether, for compatibility with older PostgreSQL
>> releases, the transaction actually runs with snapshot isolation. 
>> In any event, a request for repeatable read mode will provide the
>> existing snapshot isolation mode.
> I'm not sure a GUC is the best way here, are you talking about as a
> migration path, or something that would exist forever?
I've gotten the distinct impression that some would prefer to continue
to use their existing techniques under snapshot isolation.  I was sort
of assuming that they would want a GUC to default to legacy behavior
with a new setting for standard compliant behavior.
Another alternative here would be to just change a request for a
serializable transation to give you a serializable transaction, and
document that the existing snapshot isolation is now available only by
requesting repeatable read mode.  Right now you get snapshot isolation
mode on a request for either repeatable read mode or serializable
I think that many people only use read committed; they would not be
impacted at all.
What do you think would be best here?

In response to


pgsql-hackers by date

Next:From: Josh BerkusDate: 2009-05-27 23:57:00
Subject: Re: search_path vs extensions
Previous:From: Jeff DavisDate: 2009-05-27 23:53:10
Subject: Re: User-facing aspects of serializable transactions

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group