On Tue, Mar 8, 2016 at 12:49 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> However, after some further thought, I think we might actually be OK. >> If a page goes from all-frozen to not-all-frozen while VACUUM is >> running, any new XID added to the page must be newer than the >> oldestXmin value computed by vacuum_set_xid_limits(), so it won't >> affect the value to which we can safely set relfrozenxid. Similarly, >> any MXID added to the page will be newer than GetOldestMultiXactId(), >> so setting relminmxid is still safe for similar reasons. > > Yeah, I agree with this, as long as the issue is only that the visibility > map result is slightly stale and not that it's, say, not crash-safe.
If the visibility map isn't crash safe, we've got big problems even without this patch, but we dealt with that when index-only scans went in. Maybe this patch introduces more stringent requirements in this area, but I can't think of any reason why that should be true. If anything occurs to you (or anyone else), it would be good to mention that before I go further destroy the world. > We can reasonably assume that any newly-added XID must be one that was > in progress while VACUUM was running, and hence will be after the xmin > horizon we computed earlier. This requires the existence of a read > barrier somewhere between computing xmin horizon and inspecting the > visibility map, but I find it hard to believe there aren't plenty. I'll check that, but I agree that it should be OK. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers