Re: ALTER TABLE on system catalogs

On 2018-Sep-28, Andres Freund wrote:

> On 2018-09-28 16:06:30 -0300, Alvaro Herrera wrote:
> > On 2018-Aug-21, Andres Freund wrote:
> >
> > > I still think it's wrong to work around this than to actually fix the
> > > issue with pg_attribute not having a toast table.
> >
> > FWIW I'm still bothered by the inability to move pg_largeobject to a
> > different tablespace, per
> > https://postgr.es/m/20160502163033.GA15384@alvherre.pgsql
> > While that needs even more work (preservability across pg_dump for one),
> > this item here would be one thing to fix.
> >
> > Also, I don't quite understand what's so horrible about setting
> > autovacuum options for system catalogs, including those that don't have
> > toast tables. That seems a pretty general feature that needs fixing,
> > too.
>
> I'm not sure what that has to do with my point? What I'm saying is that
> we shouldn't have some weird "should have a toast table but doesn't"
> exception, not that we shouldn't allow any sort of DDL on catalogs.

Well, the subtext in your argument seemed to be "let's just add a
toast table to pg_attribute and then we don't need any of this". I'm
just countering that if we don't have toast tables for some catalogs,
it's because that's something we've already beaten to death; so rather
than continue to beat it, we should discuss alternative ways to attack
the resulting side-effects.

I mean, surely adding a toast table to pg_largeobject would be
completely silly. Yet if we leave this code unchanged, trying to move
it to a different tablespace would "blow up" in a way.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services