Robert Haas <robertmh...@gmail.com> writes: > The patch makes some attempt to update the comment mechanically, but > that's not nearly enough. That comment is explaining that you *can't* > rely on the visibility map to tell you *for sure* that a page does not > require vacuuming. For current uses, that's OK, because if we miss a > page we'll pick it up later. But now we want to skip vacuuming pages > for relfrozenxid/relminmxid advancement, that rationale doesn't apply. > Missing pages that need to be frozen and advancing relfrozenxid anyway > would be _bad_.
Check. > 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. 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. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers