Just as a followup to this. The process that I am using to do the upgrade is as follows:
1. Install Postgres 9.3 in /opt dir.
2. In 9.0 instance update spclocation in pg_tablespace.
3. Update the symlinks in the pg_tblspace folder.
4. Move the tablespace folders to new location.
5. Run pg_upgrade.
6. Test upgrade results on 9.3 cluster.
7. Run the sh files created by pg_upgrade.
8. Uninstall Postgres 9.3 in /opt dir.
9. Install Postgres 9.3 in default location.
10. Enjoy Postgres 9.3.
I could actually move the 9.0 cluster after moving the table spaces and install 9.3 in the default location as the documentation shows. But I haven't experimented with that scenario yet.
-Joseph
On Tue, Dec 31, 2013 at 7:06 PM, Adrian Klaver <adrian.klaver@xxxxxxxxx> wrote:
On 12/31/2013 04:03 PM, Joseph Kregloh wrote:
On Tue, Dec 31, 2013 at 5:08 PM, Adrian Klaver <adrian.klaver@xxxxxxxxx
<mailto:adrian.klaver@gmail.com>> wrote:
On 12/31/2013 01:31 PM, Joseph Kregloh wrote:
ERROR: relation "sys_errors" does not exist
LINE 1: SELECT * FROM sys_errors ORDER BY created_ts
DESC LIMIT 100;
^
********** Error **********
ERROR: relation "sys_errors" does not exist
SQL state: 42P01
Character: 15
sys_errors is a table in the tablespace correct?
Yes it is.
Completely different thought, is sys_errors in a schema other than
PUBLIC?
If so, what is your search_path setting for the new server?
I set the search_path to the same value that the 9.0 instance had and
that seemed to do the trick. I will know more on Thursday when I get
some time to play with it.
Seems I got tunnel vision on the tablespace issue and overlooked the simpler explanation initially. Good luck.
Thanks,
Happy New Year.
--
Adrian Klaver
adrian.klaver@xxxxxxxxx
