On Thu, May 9, 2013 at 06:19:31PM -0400, Bruce Momjian wrote: > > pg_upgrade already deals with the new code deciding not to create a > > toast table (by forcing it to do so anyway in binary upgrade mode). > > Yes, a good point I had forgotten. postgres --binary-upgrade mode can > force the toast table to be created to match the old cluster; see > toasting.c::create_toast_table(): > > /* > * Check to see whether the table actually needs a TOAST table. > * > * If an update-in-place toast relfilenode is specified, force toast file > * creation even if it seems not to need one. > */ > if (!needs_toast_table(rel) && > (!IsBinaryUpgrade || > !OidIsValid(binary_upgrade_next_toast_pg_class_oid))) > return false; > > > It's only the other case that's problematic -- but then AFAICS fixing > > that is just a SMOP. > > Yes, it is this opposite case where the _new_ cluster wants a TOAST > table that the old cluster doesn't have, which is what Evan is > reporting.
So, if we eventually agree we need to be able to _suppress_ creation of the TOAST table on the new cluster, I propose we do it in a similar way to how we force TOAST creation, by having pg_dump set a backend variable that is then tested in the backend to suppress TOAST table creation. I don't think we know enough about the cause of this pg_upgrade failure to know if this is necessary. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
