Skip site navigation (1) Skip section navigation (2)

Re: pg_class has no toast table?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_class has no toast table?
Date: 2010-02-06 18:04:09
Message-ID: 22927.1265479449@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: M ZDate: 2010-02-06 19:08:24
Subject: Re: remove contrib/xml2
Previous:From: Bruce MomjianDate: 2010-02-06 17:35:42
Subject: Re: psql 8.4 \c repeats version banner

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group