From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: A design for amcheck heapam verification |
Date: | 2017-05-01 21:10:02 |
Message-ID: | CAH2-WzniNW8ErVjYWHwYT1u8256fNaRx=7R=cdgWUMUJKm8yVg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Apr 28, 2017 at 6:02 PM, Peter Geoghegan <pg(at)bowt(dot)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/
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2017-05-01 21:20:47 | Re: Logical replication in the same cluster |
Previous Message | Tom Lane | 2017-05-01 20:48:26 | Faster pg_timezone_names view |