Re: User-facing aspects of serializable transactions
От | Kevin Grittner |
---|---|
Тема | Re: User-facing aspects of serializable transactions |
Дата | |
Msg-id | 4A1D8C66.EE98.0025.1@wicourts.gov обсуждение исходный текст |
Ответ на | Re: User-facing aspects of serializable transactions (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: User-facing aspects of serializable transactions
Re: User-facing aspects of serializable transactions |
Список | pgsql-hackers |
Jeff Davis <pgsql@j-davis.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 mode. I think that many people only use read committed; they would not be impacted at all. What do you think would be best here? -Kevin
В списке pgsql-hackers по дате отправления: