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@xxxxxxxxxx> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
