Re: Read Uncommitted
От | Peter Eisentraut |
---|---|
Тема | Re: Read Uncommitted |
Дата | |
Msg-id | 2f27cf50-f580-2192-9c4a-d89bffa2bd5b@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Read Uncommitted (Simon Riggs <simon@2ndquadrant.com>) |
Список | pgsql-hackers |
On 2019-12-18 16:14, Simon Riggs wrote: > On Wed, 18 Dec 2019 at 12:11, Konstantin Knizhnik > <k.knizhnik@postgrespro.ru <mailto:k.knizhnik@postgrespro.ru>> wrote: > > As far as I understand with "read uncommitted" policy we can see two > versions of the same tuple if it was updated by two transactions > both of which were started before us and committed during table > traversal by transaction with "read uncommitted" policy. Certainly > "read uncommitted" means that we are ready to get inconsistent > results, but is it really acceptable to multiple versions of the > same tuple? > > > "In general, read uncommitted will return inconsistent results and > wrong answers. If you look at the changes made by a transaction > while it continues to make changes then you may get partial results > from queries, or you may miss index entries that haven't yet been > written. However, if you are reading transactions that are paused > at the end of their execution for whatever reason then you can > see a consistent result." > > I think I already covered your concerns in my suggested docs for this > feature. Independent of the technical concerns, I don't think the SQL standard allows the READ UNCOMMITTED level to behave in a way that violates the logical requirements of the defined database schema. So if we wanted to add this, we should probably name it something else. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: