Re: Sequences not moved to new tablespace

From: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "Guillaume Drolet *EXTERN*" <droletguillaume(at)gmail(dot)com>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
Cc: PostgreSQL General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Sequences not moved to new tablespace
Date: 2015-02-24 13:45:33
Message-ID: A737B7A37273E048B164557ADEF4A58B3659FC6D@ntex2010i.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Guillaume Drolet wrote:
> Digging a little more, I found that not only sequences were not moved but also many tables in
> pg_catalog are still in my old tablespace. This is expected since the query in the SQL files I used to
> move the tables and indexes had a WHERE clause like this:
>
> SELECT ' ALTER TABLE ' || schemaname || '.' || tablename || ' SET TABLESPACE pg_default;'
> FROM pg_tables
> WHERE schemaname NOT IN ('pg_catalog', 'information_schema');
>
> So I tried removing the WHERE clause and running the script again:
> psql -U postgres -d mydb < move_tables_to_pg_default.sql | findstr /R /C:"[ALTER]" | psql -d mydb -U
> postgres
>
> I got many errors like this one:
> ERROR: permission denied: "pg_event_trigger" is a system catalog
>
> If I can't move tables from pg_catalog, how will I be able to drop that tablespace I don't want to use
> anymore?
>
> I am thinking that maybe using "ALTER DATABASE mydb SET TABLESPACE pg_default;" instead would take
> care of all this, no?
>
> But when I tried it last week, I got a message like: some relations already in target tablespace...
>
> Any help will be much appreciated.

If you want to move a whole database to a different tablespace (the only reason
I can think of for doing what you are trying to so), use the command
ALTER DATABASE ... SET TABLESPACE ...

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message George Woodring 2015-02-24 14:25:29 Re: SQL solution for my JDBC timezone issue
Previous Message Sergey Shchukin 2015-02-24 13:42:06 Issue with a hanging apply process on the replica db after vacuum works on primary