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.
