Robert Haas <robertmh...@gmail.com> writes: > The problem is that if a relfilenode ever gets assigned by > GetNewRelFileNode() during a binary-upgrade restore, that OID may turn > out to be used by some other object later in the dump. And then > you're dead, because the dump restore will fail later on complaining > about, well, I forget the error message wording exactly, but, > basically, an OID collision.
Right. > So if we change the rules in such a way > that objects which currently lack TOAST tables acquire them, we need > to first restore all of the objects *without* adding any new TOAST > tables, and then at the end create any new TOAST tables once we have a > complete list of the relfilenodes that are actually used. toasting.c explains why this currently doesn't seem necessary: /* * In binary-upgrade mode, create a TOAST table if and only if * pg_upgrade told us to (ie, a TOAST table OID has been provided). * * This indicates that the old cluster had a TOAST table for the * current table. We must create a TOAST table to receive the old * TOAST file, even if the table seems not to need one. * * Contrariwise, if the old cluster did not have a TOAST table, we * should be able to get along without one even if the new version's * needs_toast_table rules suggest we should have one. There is a lot * of daylight between where we will create a TOAST table and where * one is really necessary to avoid failures, so small cross-version * differences in the when-to-create heuristic shouldn't be a problem. * If we tried to create a TOAST table anyway, we would have the * problem that it might take up an OID that will conflict with some * old-cluster table we haven't seen yet. */ I don't really see any near-term reason why we would need to change this. 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. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers