Re: Pg_upgrade and toast tables bug discovered
От | Robert Haas |
---|---|
Тема | Re: Pg_upgrade and toast tables bug discovered |
Дата | |
Msg-id | CA+TgmobeQLF9_1+BMDhY5NhV6M44WT9eNntZjJhLyX=EaVd2rA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Pg_upgrade and toast tables bug discovered (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: Pg_upgrade and toast tables bug discovered
Re: Pg_upgrade and toast tables bug discovered |
Список | pgsql-hackers |
On Fri, Jul 11, 2014 at 9:55 AM, Bruce Momjian <bruce@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? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: