Re: Serializable implementation
От | Jeff Davis |
---|---|
Тема | Re: Serializable implementation |
Дата | |
Msg-id | 1262917230.5908.606.camel@monkey-cat.sm.truviso.com обсуждение исходный текст |
Ответ на | Re: Serializable implementation (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Serializable implementation
|
Список | pgsql-hackers |
On Thu, 2010-01-07 at 21:02 -0500, Robert Haas wrote: > Hmm. Why would we use a GUC for this instead of an additional option > to BEGIN TRANSACTION? I'm with you. I feel pretty strongly that we should not have behavior-changing GUCs. I make an exception for compatibility GUCs where the eventual default will be the new behavior, the vast majority of users will be using the new behavior in a release or two, and we just have the GUC to allow backwards compatibility for a while (and would be willing to potentially eliminate the GUC in a few releases). The last thing we want are 103 behavior-changing GUCs that vary widely in their settings among users. > BEGIN TRANSACTION ISOLATION LEVEL {READ COMMITTED | SNAPSHOT | SERIALIZABLE} > > With our current levels being the first two of those. > > Or is that a bad idea? We already have REPEATABLE READ which already has the same semantics as SNAPSHOT would have, so I don't think we need to introduce a new one. I think the only thing we need to do is suggest that people start using REPEATABLE READ if they want snapshot isolation. That will give us more freedom to change SERIALIZABLE to be true serializability in 8.6. If we need a GUC that aliases SERIALIZABLE to REPEATABLE READ for backwards compatibility (after we change SERIALIZABLE) for a short period of time, that sounds reasonable. Even that may not be necessary though because it shouldn't really break any promises that we made in the documentation (that I'm aware of). Regards,Jeff Davis
В списке pgsql-hackers по дате отправления: