On Mon, Jul 7, 2014 at 11:24:51AM -0400, Robert Haas wrote:
> > As far as the reusing of oids, we don't set the oid counter until after
> > the restore, so any new unmatched toast table would given a very low
> > oid. Since we restore in oid order, for an oid to be assigned that was
> > used in the old cluster, it would have to be a very early relation, so I
> > think that reduces the odds considerably. I am not inclined to do
> > anything more to avoid this until I see an actual error report ---
> > trying to address it might be invasive and introduce new errors.
>
> That sounds pretty shaky from where I sit. I wonder if the
> pg_upgrade_support module should have a function
> create_toast_table_if_needed(regclass) or something like that. Or
> maybe just create_any_missing_toast_tables(), iterating over all
> relations.
Uh, I guess we could write some code that iterates over all tables and
finds the tables that should have TOAST tables, but don't (because
binary-upgrade backend mode suppressed their creation), and adds them.
However, that would be a lot of code and might be risky to backpatch.
The error is so rare I am not sure it is worth it. I tried to create
the failure case and it was very difficult, requiring me to create the
problem table first, then some dummy stuff to get the offsets right so
the oid would collide.
Based on the rareness of the bug, I am not sure it is worth it, but if
it is, it would be something only for 9.4 (maybe) and 9.5, not something
to backpatch.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +
