Andres Freund <and...@anarazel.de> writes: > In my opinion the problem of:
> On 2017-06-12 17:13:34 -0400, Tom Lane wrote: >> assignments of relfilenodes have to be shortcircuited by pg_upgrade >> override calls during a binary-restore run, or we risk filename >> collisions. > should instead be solved by simply not even trying to preserve > relfilenodes. We can "just" copy/link files to the the new > relfilenodes, there's no need to preserve them, in contrast to > pg_class.oid etc. But that's obviously something for the future. Right. But until somebody gets around to fixing that, it's a problem. Also, even if we fix this, we still have the issue of type OIDs residing on-disk in places like array headers; that results in pg_upgrade having to control type OID assignments as well. I thought about trying to insert an assert in GetNewOidWithIndex to ensure that no type OIDs are selected automatically during upgrade, but it seemed a bit too complicated. Might be a good idea to figure it out though, unless you have an idea for removing that requirement. >> I intend to not only commit this, but back-patch it. There's enough >> changes in relevant code paths that logic that is fine in HEAD might >> not be fine in back branches. > Hm. Just found out that 9.4 (and probably older) fail the assertion because of the temp table created in get_rel_infos(). That's *probably* all right because the table is *probably* gone from disk by the time we start the actual restore run. But we start the new postmaster only once, with -b, so the assertion applies to the preparatory steps as well as the restore proper. Later versions avoid that by using a CTE instead of a temp table. I'm not excited enough about this to back-port the patch that changed it, so I'm thinking of just adding the assert back to 9.5. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers