Re: Read Uncommitted - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Read Uncommitted
Date
Msg-id CANP8+jJioT3rM1UT_QSeJbLy4wJv8doCht-kdLvZt34d-dhz2A@mail.gmail.com
Whole thread Raw
In response to Re: Read Uncommitted  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Read Uncommitted  (Robert Haas <robertmhaas@gmail.com>)
Re: Read Uncommitted  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Read Uncommitted  (Mark Dilger <hornschnorter@gmail.com>)
Re: Read Uncommitted  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Wed, 18 Dec 2019 at 17:35, Robert Haas <robertmhaas@gmail.com> wrote:
On Wed, Dec 18, 2019 at 10:18 AM Simon Riggs <simon@2ndquadrant.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/
PostgreSQL Solutions for the Enterprise

pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: RE: Windows port minor fixes
Next
From: Fabrízio de Royes Mello
Date:
Subject: Re: Restore backup file "with oids"