Re: Read Uncommitted - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Read Uncommitted
Date
Msg-id 2f27cf50-f580-2192-9c4a-d89bffa2bd5b@2ndquadrant.com
Whole thread Raw
In response to Re: Read Uncommitted  (Simon Riggs <simon@2ndquadrant.com>)
List 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 by date:

Previous
From: Tatsuro Yamada
Date:
Subject: Re: progress report for ANALYZE
Next
From: Bernd Helmle
Date:
Subject: Re: Read Uncommitted