Re: determine snapshot after obtaining locks for first statement
От | Robert Haas |
---|---|
Тема | Re: determine snapshot after obtaining locks for first statement |
Дата | |
Msg-id | 603c8f070912170958s619ad3cey332b0a4f254138cd@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: determine snapshot after obtaining locks for first statement ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: determine snapshot after obtaining locks for first
statement
Re: determine snapshot after obtaining locks for first statement Re: determine snapshot after obtaining locks for first statement |
Список | pgsql-hackers |
On Thu, Dec 17, 2009 at 12:51 PM, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> I'm not very sure what a clearer explanation would look like > > As a stab at it, how about?: > > This behavior makes Read Committed mode unsuitable for many UPDATE > or DELETE commands with joins or subqueries I don't think that's any clearer, though it is more disparaging. :-) Note we also say: "The partial transaction isolation provided by Read Committed mode is adequate for many applications, and this mode is fast and simple to use; however, it is not sufficient for all cases. Applications that do complex queries and updates might require a more rigorously consistent view of the database than Read Committed mode provides." ...Robert
В списке pgsql-hackers по дате отправления: