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: http://www.postgresql.org/mailpref/pgsql-hackers