Re: User-facing aspects of serializable transactions

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