On 21 March 2017 at 20:04, Bruce Momjian <br...@momjian.us> wrote: > Yes, but once it is written it will take years before those bits can be > used on most installations.
Well the problem isn't most installations. On most installations it should be pretty straightforward to check the oldest database xid and compare that to when the database was migrated to post-9.0. (Actually there may be some additional code to write but it's just ensuring that the bits are actually cleared and not just ignored but even so databases do generally need to be vacuumed more often than on the order of years though.) The problem is that somebody tomorrow could upgrade an 8.4 database to 10.0. In general it seems even versions we don't support get extra support for migrating away from. I assume it's better to help support upgrading than to continue to have users using unsupported versions... And even if you're not concerned about 8.4 someone could still upgrade 9.4 for years to come. It probably does make sense pick a version, say, 10.0, and have it go out of its way to ensure it cleans up the MOVED_IN/MOVED_OFF so that we can be sure that any database was pg_upgraded from 10.0+ doesn't have any left. Then at least we'll know when the bits are available again. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
