On 01/10/2014 06:59 PM, Bruce Momjian wrote:
> On Fri, Dec 27, 2013 at 04:10:25PM -0800, Adrian Klaver wrote:
>> On 12/27/2013 02:52 PM, Jeff Janes wrote:
>>> On Friday, December 27, 2013, Joseph Kregloh wrote:
>>>
>>> FYI, some testing showed that playing around with spclocation in
>>> pg_tablespace is not recommended.
>>>
>>>
>>> Do you happen to have more information about this? Because it would
>>> actually solve all my problems by moving the user created
>>> tablespaces out of the /data directory. But I would like more
>>> information on the subject before even thinking about it anymore. I
>>> did it a couple times for testing purposes. I modified the
>>> spclocation in pg_tablespace and then move the folder.
>>>
>>>
>>> spclocation no longer exists in 9.3. If the database needs to know
>>> where the location is, it inspects the symlink in pg_tblspc to figure
>>> that out.
>>
>> Well the issue seems to be with 9.0. I am not exactly sure where
>> pg_upgrade is pulling its information, but I am guessing from the
>> error message that on the 9.0 side of things it is using
>> spclocation. In the OPs situation that is no longer valid for 9.0
>> once its data directory is moved. The special circumstance here
>> being that the user tablespace is in PGDATA. I would welcome
>> enlightenment on this.
>
> The problem is that pre-9.2 recorded the tablespace location in
> pg_tablespace and in the symlink. When the pg_upgrade instructions tell
> you to rename the old database cluster, it doesn't remind pre-9.2 users
> to update in-PGDATA tablespaces.
Just so I understand, this is update spclocation in pg_upgrade in the
pre-9.2 database.
>
> Only the symlink location is used in 9.2+, so it would work fine there.
>
--
Adrian Klaver
adrian.klaver@gmail.com