Re: [HACKERS] A design for amcheck heapam verification - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: [HACKERS] A design for amcheck heapam verification
Date
Msg-id CAH2-WzniNW8ErVjYWHwYT1u8256fNaRx=7R=cdgWUMUJKm8yVg@mail.gmail.com
Whole thread Raw
In response to [HACKERS] A design for amcheck heapam verification  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: [HACKERS] A design for amcheck heapam verification  (Peter Geoghegan <pg@bowt.ie>)
Re: [HACKERS] A design for amcheck heapam verification  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Apr 28, 2017 at 6:02 PM, Peter Geoghegan <pg@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/



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: [HACKERS] Faster pg_timezone_names view
Next
From: Greg Stark
Date:
Subject: Re: [HACKERS] Logical replication in the same cluster