Re: determine snapshot after obtaining locks for first statement
От | Kevin Grittner |
---|---|
Тема | Re: determine snapshot after obtaining locks for first statement |
Дата | |
Msg-id | 4B2A2C8B020000250002D738@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: determine snapshot after obtaining locks for first statement (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> wrote: > Don't get me wrong, I don't love the current behavior. (I don't > have a competing proposal either.) But I think we want to > describe it with precision, because there are also many cases > where _it works fine_. Telling people when it works and when it > doesn't work is a lot more useful than attempting to qualitatively > estimate how good or bad it is. It sounds like we're in violent agreement. I'm not sure what I said which might have led you to believe I felt otherwise. [reviews thread] The suggestion you felt was "more disparaging" was: : This behavior makes Read Committed mode unsuitable for : many UPDATE or DELETE commands with joins or subqueries You do realize that what is already in the documentation, for which this was a suggested replacement, was?: : This behavior makes Read Committed mode unsuitable for : commands that involve complex search conditions I'm not seeing where I made it more disparaging; I was trying to clarify under what circumstances it was a problem. If you have a suggestion for a better way to phrase the part I left alone, feel free to suggest something. -Kevin
В списке pgsql-hackers по дате отправления: