Re: Read Uncommitted - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Read Uncommitted
Date
Msg-id CANP8+jJ0Yidtwx5LdHOzJ9jqKu8b5m3N__j4OMDZ4k9cG=9w7A@mail.gmail.com
Whole thread Raw
In response to Re: Read Uncommitted  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Responses Re: Read Uncommitted  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List 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
    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/
PostgreSQL Solutions for the Enterprise

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: psql's EDITOR behavior on Windows
Next
From: Simon Riggs
Date:
Subject: Re: Read Uncommitted