On 2015-12-09 20:23:06 -0500, Noah Misch wrote: > By the way, it occurs to me that I should also make pg_upgrade blacklist the > range of catversions that might have data loss. No sense in putting ourselves > in the position of asking whether data files of a 9.9.3 cluster spent time in > a 9.5beta2 cluster.
I can't see any benefit in that. We're talking about a bug that, afaics, needs another unknown bug to trigger (so find_multixact_start() fails), and then very likely needs significant amounts of new multixacts consumed, without a restart and without find_multixact_start() succeeding later. What I think would actually help for questions like this, is to add, as discussed in some other threads, the following: 1) 'creating version' to pg_control 2) 'creating version' to each pg_class entry 3) 'last relation rewrite in version' to each pg_class entry 4) 'last full vacuum in version' to each pg_class entry I think for this purpose 'version' should be something akin to $catversion||$numericversion (int64 probably?) - that way development branches and release branches are handled somewhat usefully. I think that'd be useful, both from an investigatory perspective, as from a tooling perspective, because it'd allow reusing things like hint bits. > > Ripping it out and replacing it monolithically will not > > change that; it will only make the detailed history harder to > > reconstruct, and I *will* want to reconstruct it. > > What's something that might happen six months from now and lead you to inspect > master or 9.5 multixact.c between 4f627f8 and its revert? "Hey, what has happened to multixact.c lately? I'm investigating a bug, and I wonder if it already has been fixed?", "Uh, what was the problem with that earlier large commit?", "Hey, what has changed between beta2 and the final release?"... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers