On Wed, 18 Dec 2019 at 17:35, Robert Haas <robertmh...@gmail.com> wrote:
> On Wed, Dec 18, 2019 at 10:18 AM Simon Riggs <si...@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/ <http://www.2ndquadrant.com/> PostgreSQL Solutions for the Enterprise
