> 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
In response to
pgsql-hackers by date
|Next:||From: M Z||Date: 2010-02-06 19:08:24|
|Subject: Re: remove contrib/xml2|
|Previous:||From: Bruce Momjian||Date: 2010-02-06 17:35:42|
|Subject: Re: psql 8.4 \c repeats version banner|