On Fri, Apr 28, 2017 at 6:02 PM, Peter Geoghegan <p...@bowt.ie> wrote: > - Is committed, and committed before RecentGlobalXmin.
Actually, I guess amcheck would need to use its own scan's snapshot xmin instead. This is true because it cares about visibility in a way that's "backwards" relative to existing code that tests something against RecentGlobalXmin. Is there any existing thing that works that way? If it's not clear what I mean: existing code that cares about RecentGlobalXmin is using it as a *conservative* point before which every snapshot sees every transaction as committed/aborted (and therefore nobody can care if that other backend hot prunes dead tuples from before then, or whatever it is). Whereas, amcheck needs to care about the possibility that *anyone else* decided that pruning or whatever is okay, based on generic criteria, and not what amcheck happened to see as RecentGlobalXmin during snapshot acquisition. -- Peter Geoghegan VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
