On Tue, Jun 13, 2017 at 9:37 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > In the long run, it would certainly be cleaner if pg_upgrade dropped > the force-the-relfilenode-assignment approach and instead remapped > relfilenodes from old cluster to new. But I think it's just for > cleanliness rather to fix any live or foreseeable bug.
Honestly, I think that would probably be *less* robust overall. I think we ought to be driving in the direction of having more and more things common between the old and new clusters, rather than trying to cope with them being different. It's pretty easy for users to have hidden dependencies on values that we think are only for internal use - e.g. somebody's got a table column of type regclass, and it breaks if you changed the table OIDs. A table with relfilenode values in it is perhaps less likely, but it is not beyond imagining that someone (who wrote a replication system?) has a use for it. Now maybe you're going to say "that's not a good idea", and maybe you're right, but users don't enjoy being told that something they've been doing for years works all the time *except* when you use pg_upgrade. Also, I think that if we did it that way, it would be significantly harder to debug. Right now, if something goes boom, you can look at the old and new clusters and figure out what doesn't match, but if pg_upgrade renumbered everything, you would no longer be able to do that, or at least not easily. -- 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
