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.
Only the symlink location is used in 9.2+, so it would work fine there.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +