Robert Haas <> 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.


> 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 (
To make changes to your subscription:

Reply via email to