Re: help with moving tablespace - Mailing list pgsql-general

From
Subject Re: help with moving tablespace
Date
Msg-id 20161117101933.F994E02@m0087798.ppops.net
Whole thread Raw
In response to help with moving tablespace  ("" <kbrannen@pwhome.com>)
List pgsql-general
> On Thu, Nov 17, 2016 <david.g.johnston@gmail.com> wrote:
> > On Thu, Nov 17, 2016 at 9:16 AM, <kbrannen@pwhome.com> wrote:
> > First, the above works only *most* of the time in our testing on multiple servers. When it fails, it's because not
everythingwas moved out of the old tablespace and I don't understand why. An "ls $PGDATA/ourdb/PG*/" shows files are
stillpresent. According to some searching, I should be able to do: 
>
>
> Likely more than one database in the cluster is using $PGDATA/ourdb as its default tablespace location so you need to
alterall of them. 

Sigh, it's so easy to overlook the obvious; thanks for pointing that out. Knowing what to look for and with some
research,doing: 

    select datname,dattablespace,spcname from pg_database join pg_tablespace on dattablespace = pg_tablespace.oid;

shows there is indeed an extra schema using that tablespace that I'll need to drop or move. Hopefully that helps
someoneelse. 


> pg_class displays relative to the current database only so you need to log into the others to check them.

Right, something else I didn't consider.


> > Second, the "ALTER DATABASE ourdb SET TABLESPACE new_ts" which does the move is slow even on our smaller test DBs,
almostas if it is having to dump and reload (or more likely copy) the data. This raises the concern of how long this is
goingto take on our bigger DBs. Is there a faster way to accomplish the same thing especially since the new and old
tablespacesare on the same disk partition? 
> >
> > For example, from what I can see the data is sitting in a dir and there is a symlink to it in $PGDATA/pg_tblspc.
> >
> > Could I shut down PG, move the DB dir, recreate the symlink in pg_tblspc, then restart PG and all would be well in
onlya few seconds? 
>
>
> I think this would work - all the SQL commands do is invoke O/S commands on your behalf and I'm reasonably certain
thisis what they end up doing.  Given that you are indeed testing you should try this and make sure.  Its either going
towork, or not, I don't foresee (in my limited experience...) any delayed reaction that would be likely to arise. 


Thanks! That gives me confidence to give that method a try.

Kevin


pgsql-general by date:

Previous
From: Israel Brewster
Date:
Subject: Re: Streaming replication failover/failback
Next
From: dhaval jaiswal
Date:
Subject: Re: pg_class (system) table increasing size.