Bruce Momjian wrote > On Wed, Aug 27, 2014 at 09:05:41AM -0400, Robert Haas wrote: >> Another idea is to have a command that you can run, while connected to >> a particular database, that updates the default tablespace for that >> database without actually moving any data on disk - i.e. it sets >> pg_database.dattablespace, and then updates every pg_class row where >> reltablespace = 0 to the old default tablespace, and pg_class row >> where reltablespace = the new tablespace ID to 0. Then you can move >> individual relations afterwards if you feel like it. But that might >> still require a lot of locks, and I think we also have a limitation >> that some relations (the mapped ones?) have to be in the database's >> default tablespace, which obviously wouldn't work here. >> >> So it's a tricky problem. > > Is there a doc patch to make here?
1. Last sentence change suggestion: "The target tablespace must be empty." 2. Based on Robert's comments it sounds like a "You cannot change the default tablespace of the current database." comment should be added as well. Side note: I have no clue what the "mapped relations" Robert refers to are... If the locking problem is unsolvable, which seems to be the only realistic reason why updating pg_class cannot be done somewhere in the process, could we make it so that the same physical tablespace location can have multiple pointers? The problem here would be that a subsequent move would only grab those relations that are in the current tablespace by default and would leave the ones that were present originally - unless they get moved in the interim to the default tablespace (in this case by changing their oid to 0 manually first). David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Code-bug-or-doc-bug-tp5816052p5816550.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers