Re: Read Uncommitted

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Read Uncommitted
Date: 2019-12-18 18:06:21
Message-ID: CANP8+jJioT3rM1UT_QSeJbLy4wJv8doCht-kdLvZt34d-dhz2A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 18 Dec 2019 at 17:35, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Wed, Dec 18, 2019 at 10:18 AM Simon Riggs <simon(at)2ndquadrant(dot)com>
> wrote:
> > This was my first concern when I thought about it, but I realised that
> by taking a snapshot and then calculating xmin normally, this problem would
> go away.
>
> Why? As soon as a transaction aborts...
>

So this is the same discussion as elsewhere about potentially aborted
transactions...
AFAIK, the worst that happens in that case is that the reading transaction
will end with an ERROR, similar to a serializable error.

And that won't happen in the use cases I've explicitly described this as
being useful for, which is where the writing transactions have completed
executing.

I'm not claiming any useful behavior outside of those specific use cases;
this is not some magic discovery that goes faster - the user has absolutely
no reason to run this whatsoever unless they want to see uncommitted data.
There is a very explicit warning advising against using it for anything
else.

Just consider this part of the recovery toolkit.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Solutions for the Enterprise

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabrízio de Royes Mello 2019-12-18 18:06:58 Re: Restore backup file "with oids"
Previous Message Ranier Vilela 2019-12-18 17:36:18 RE: Windows port minor fixes