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
