On Thu, May 9, 2013 at 06:05:14PM -0400, Alvaro Herrera wrote:
> Greg Stark escribió:
> > On Thu, May 9, 2013 at 10:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > > In any case, it seems like pg_upgrade ought to have a strategy for
> > > dealing with tables acquiring toast tables like this,
> >
> > Acquiring toast tables seems pretty trivial to deal with. *Losing* a
> > toast table might be a bit more involved...
>
> 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
relfilenodeis 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.
Evan, have you adjusted the TOAST storage parameters for this table at
all, via ALTER TABLE SET STORAGE?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
