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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers