On Fri, Oct 6, 2017 at 11:34 AM, Peter Geoghegan <p...@bowt.ie> wrote: >> I don't know if it's really the freeze map at fault or something else. > > Ideally, it would be possible to effectively disable the new freeze > map stuff in a minimal way, for testing purposes. Perhaps the authors > of that patch, CC'd, can suggest a way to do that.
Actually, the simplest thing might be to just use pg_visibility's pg_check_frozen() to check that the visibility/freeze map accurately summarizes the all-frozen status of tuples in the heap. If that doesn't indicate that there is corruption, we can be fairly confident that the problem is elsewhere. The metadata in the visibility/freeze map should be accurate when a bit is set to indicate that an entire heap page is all-frozen (or, separately, all-visible). We can hardly expect it to have better information that the authoritative source of truth, the heap itself. The more I think about it, the more I tend to doubt that the remaining problems are with the freeze map. If the freeze map was wrong, and incorrectly said that a page was all-frozen, then surely the outward symptoms would take a long time to show up, as they always do when we accidentally fail to freeze a tuple before a relfrozenxid cutoff. ISTM that that's the only meaningful way that the freeze map can be wrong -- it only promises to be accurate when it says that no further freezing is needed for a page/bit. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers