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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to