Re: Pg_upgrade and toast tables bug discovered - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Pg_upgrade and toast tables bug discovered
Date
Msg-id 20140711135534.GG7366@momjian.us
Whole thread Raw
In response to Re: Pg_upgrade and toast tables bug discovered  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Pg_upgrade and toast tables bug discovered
Re: Pg_upgrade and toast tables bug discovered
List pgsql-hackers
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.

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



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Pg_upgrade and toast tables bug discovered
Next
From: Alvaro Herrera
Date:
Subject: Re: add line number as prompt option to psql