On Thu, Nov 17, 2016 at 9:16 AM, <kbran...@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 everything was moved out of the > old tablespace and I don't understand why. An "ls $PGDATA/ourdb/PG*/" shows > files are still present. 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 alter all of them. > SELECT c.relname, t.spcname > FROM pg_class c JOIN pg_tablespace t ON c.reltablespace = t.oid > WHERE t.spcname = 'old_name'; > > But that always returns 0 rows. So how do I track this down? > pg_class displays relative to the current database only so you need to log into the others to check them. > Second, the "ALTER DATABASE ourdb SET TABLESPACE new_ts" which does the > move is slow even on our smaller test DBs, almost as if it is having to > dump and reload (or more likely copy) the data. This raises the concern of > how long this is going to take on our bigger DBs. Is there a faster way to > accomplish the same thing especially since the new and old tablespaces are > 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 only a 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 this is what they end up doing. Given that you are indeed testing you should try this and make sure. Its either going to work, or not, I don't foresee (in my limited experience...) any delayed reaction that would be likely to arise. David J.
