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@xxxxxxxxx
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
