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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers