On Mon, May 1, 2017 at 6:20 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Maybe you can fix this by assuming that your own session's advertised xmin > is a safe upper bound on everybody else's RecentGlobalXmin. But I'm not > sure if that rule does what you want.
That's what you might ultimately need to fall back on (that, or perhaps repeated calls to GetOldestXmin() to recheck, in the style of pg_visibility). It's useful to do rechecking, rather than just starting with the MVCC snapshot's xmin because you might be able to determine that the absence of some index tuple in the index (by which I mean its bloom filter) *still* cannot be explained by concurrent recycling. The conclusion that there is a real problem might never have been reached without this extra complexity. I'm not saying that it's worthwhile to add this complexity, rather than just starting with the MVCC snapshot's xmin in the first place -- I really don't have an opinion either way just yet. -- 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
