On Mon, Jul 14, 2014 at 11:26:19AM -0400, Robert Haas wrote:
> On Fri, Jul 11, 2014 at 9:55 AM, Bruce Momjian <br...@momjian.us> wrote:
> > On Fri, Jul 11, 2014 at 09:48:06AM -0400, Bruce Momjian wrote:
> >> > Uh, why does this need to be in ALTER TABLE?  Can't this be part of
> >> > table creation done by pg_dump?
> >>
> >> Uh, I think you need to read the thread.  We have to delay the toast
> >> creation part so we don't use an oid that will later be required by
> >> another table from the old cluster.  This has to be done after all
> >> tables have been created.
> >>
> >> We could have pg_dump spit out those ALTER lines at the end of the dump,
> >> but it seems simpler to do it in pg_upgrade.
> >>
> >> Even if we have pg_dump create all the tables that require pre-assigned
> >> TOAST oids first, then the other tables that _might_ need a TOAST table,
> >> those later tables might create a toast oid that matches a later
> >> non-TOAST-requiring table, so I don't think that fixes the problem.
> >
> > What would be nice is if I could mark just the tables that will need
> > toast tables created in that later phase (those tables that didn't have
> > a toast table in the old cluster, but need one in the new cluster).
> > However, I can't see where to store that or how to pass that back into
> > pg_upgrade.  I don't see a logical place in pg_class to put it.
> reloptions?

Yes, that might work.  I thought about that but did not have time to see
if we can easily add/remove reloptions at the C level in that area of
the code.

  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