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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
