On Sat, 2010-02-06 at 13:04 -0500, Tom Lane wrote:
> I wrote:
> > Still fooling with VACUUM FULL on catalogs ... I find that a sanity
> > check I put in is barfing on "VACUUM FULL pg_class", because the
> > transient table is built with a toast table, whereas pg_class hasn't got
> > one. It seems like it probably ought to have one, because either relacl
> > or reloptions could in principle be too big to fit without toasting
> > (which is exactly why AlterTableCreateToastTable thinks it should make
> > one for the transient table).
>
> > I have a vague feeling that we intentionally omitted a toast table for
> > pg_class, but I don't remember why. Comments?
> BTW, I decided not to touch this issue in the current patch --- it turns
> out there are quite a few system catalogs that lack a toast table but
> AlterTableCreateToastTable's rules would say to create one. The one
> that made me stop adding them was pg_largeobject. That has a bytea
> column but there are usage rules that limit the possible width of the
> column, and of course AlterTableCreateToastTable doesn't know that.
>
> So I tweaked the CLUSTER/VAC FULL logic to never add a toast table if
> the original table hasn't got one. (It can still *remove* a toast
> table, as might happen after dropping a wide column for instance.)
>
> We might still want to consider toast-ifying pg_class if anyone ever
> complains about not having room for wide relacl values; but CLUSTER
> shouldn't be a forcing function for such decisions.
What failure do you get if you have too many relacls or too many
reloptions? We would want it to fail cleanly. Is it enough to mark those
columns as MAIN storage?
Neither of those is worth worrying about a toast table for. Anybody with
that long a relacl hasn't thought about their admin structure enough.
-- Simon Riggs www.2ndQuadrant.com
