On Fri, Jul 4, 2014 at 11:12:58PM -0400, Bruce Momjian wrote: > On Fri, Jul 4, 2014 at 12:01:37AM -0400, Bruce Momjian wrote: > > > The most robust, but not trivial, approach seems to be to prevent toast > > > table creation if there wasn't a set_next_toast_pg_class_oid(). Then, > > > after all relations are created, iterate over all pg_class entries that > > > possibly need toast tables and recheck if they now might need one. > > > > Wow, that is going to be kind of odd in that there really isn't a good > > way to create toast tables except perhaps add a dummy TEXT column and > > remove it. There also isn't an easy way to not create a toast table, > > but also find out that one was needed. I suppose we would have to > > insert some dummy value in the toast pg_class column and come back later > > to clean it up. > > > > I am wondering what the probability of having a table that didn't need a > > toast table in the old cluster, and needed one in the new cluster, and > > there being an oid collision. > > > > I think the big question is whether we want to go down that route. > > Here is an updated patch. It was a little tricky because if the > mismatched non-toast table is after the last old relation, you need to > test differently and emit a different error message as there is no old > relation to complain about. > > 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.
Patch applied back through 9.2. 9.1 and earlier had code that was different enought that I thought it would cause too many problems, and I doubt many users are doing major uprades to 9.1, and the bug is rare. -- 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