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.kla...@gmail.com>wrote: > On 12/31/2013 04:03 PM, Joseph Kregloh wrote: > >> >> >> >> On Tue, Dec 31, 2013 at 5:08 PM, Adrian Klaver <adrian.kla...@gmail.com >> <mailto:adrian.kla...@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.kla...@gmail.com >
