From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Read Uncommitted |
Date: | 2019-12-18 15:14:20 |
Message-ID: | CANP8+jJ0Yidtwx5LdHOzJ9jqKu8b5m3N__j4OMDZ4k9cG=9w7A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 18 Dec 2019 at 12:11, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)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.
I'm not suggesting it for general use.
--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Solutions for the Enterprise
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2019-12-18 15:15:29 | Re: BUG #16171: Potential malformed JSON in explain output |
Previous Message | Tom Lane | 2019-12-18 15:11:16 | Re: psql's EDITOR behavior on Windows |