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.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
