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

Re: User-facing aspects of serializable transactions

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: User-facing aspects of serializable transactions
Date: 2009-05-27 23:53:10
Message-ID: 1243468390.24838.153.camel@monkey-cat.sm.truviso.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, 2009-05-27 at 15:34 -0500, Kevin Grittner wrote:
> (2)  The standard requires this because it is the only cost-effective
> way to ensure data integrity in some environments, particularly those
> with a large number of programmers, tables, and queries; and which
> have complex data integrity rules.  Basically, any serializable
> transaction which can be shown to do the right thing when run by
> itself will automatically, with no additional development effort, do
> the right thing when run in any arbitrary mix of concurrent
> transactions.  This feature would be likely to make PostgreSQL a
> viable option in some shops where it currently isn't.

+1. It would be great if this could be accomplished with reasonable
performance, or at least predictable performance.
 
> (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?

Regards,
        Jeff Davis


In response to

Responses

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2009-05-27 23:54:31
Subject: Re: User-facing aspects of serializable transactions
Previous:From: Tom LaneDate: 2009-05-27 23:24:04
Subject: Re: dblink patches for comment

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