Re: Weird behaviour with the new MOVE clause of ALTER TABLESPACE

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Weird behaviour with the new MOVE clause of ALTER TABLESPACE
Date: 2014-05-09 21:16:48
Message-ID: 20140509211648.GQ2556@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Guillaume,

* Guillaume Lelarge (guillaume(at)lelarge(dot)info) wrote:
> Should information_schema tables be moved and not pg_catalog ones? it
> doesn't seem consistent to me.

The catalog tables are moved by changing the database's tablespace, eg:

ALTER DATABASE ... SET TABLESPACE

That also moves any objects which are not assigned to a specific
tablespace.

The question ends up being just which side of "is it part of the
catalog, or not?" the information schema falls on to. For this case, I
had considered those to *not* be part of the catalog as they can be
moved independently of the ALTER DATABASE ... SET TABLESPACE.

This is happily documented:

System catalogs will not be moved by this command- individuals wishing to
move a whole database should use ALTER DATABASE, or call ALTER TABLE on the
individual system catalogs. Note that relations in <literal>information_schema</literal>
will be moved, just as any other normal database objects, if the user is the
superuser or considered an owner of the relations in <literal>information_schema</literal>.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-05-09 21:22:03 Re: test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)
Previous Message Andres Freund 2014-05-09 20:50:24 Re: pg_class.relpages/allvisible probably shouldn't be a int4