Re: pg_upgrade & tablespaces

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(dot)klaver(at)gmail(dot)com>wrote:

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