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 по дате отправления: