Re: Read Uncommitted
| От | Simon Riggs |
|---|---|
| Тема | Re: Read Uncommitted |
| Дата | |
| Msg-id | CANP8+jJ0Yidtwx5LdHOzJ9jqKu8b5m3N__j4OMDZ4k9cG=9w7A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Read Uncommitted (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>) |
| Ответы |
Re: Read Uncommitted
|
| Список | pgsql-hackers |
On Wed, 18 Dec 2019 at 12:11, Konstantin Knizhnik <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
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."
see a consistent result."
I think I already covered your concerns in my suggested docs for this feature.
I'm not suggesting it for general use.
В списке pgsql-hackers по дате отправления: