Re: pg_upgrade error attempting to upgrade from PostgreSQL 9.1.6 with postgis 2.1.1 to PostgreSQL 9.3.0

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: fburgess(at)radiantblue(dot)com
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: pg_upgrade error attempting to upgrade from PostgreSQL 9.1.6 with postgis 2.1.1 to PostgreSQL 9.3.0
Date: 2013-12-03 02:43:42
Message-ID: 20131203024342.GT5274@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Mon, Dec 2, 2013 at 04:32:27PM -0700, fburgess(at)radiantblue(dot)com wrote:
> Using pg_upgrade to upgrade from postgreSQL 9.1.6 with Postgis 2.1.1 to
> PostgreSQL 9.3.0 with Postgis 2.1.1
>
> Does anyone know why I'm getting the following error.
>
> thanks
>
>
> Performing Upgrade
> ------------------
> Analyzing all rows in the new cluster ok
> Freezing all rows on the new cluster ok
> Deleting files from new pg_clog ok
> Copying old pg_clog to new server ok
> Setting next transaction ID for new cluster ok
> Setting oldest multixact ID on new cluster ok
> Resetting WAL archives ok
> Setting frozenxid counters in new cluster ok
> Restoring global objects in the new cluster ok
> Adding support functions to new cluster ok
> Restoring database schemas in the new cluster
> ok
> Removing support functions from new cluster ok
> Adding ".old" suffix to old global/pg_control ok
>
> If you want to start the old cluster, you will need to remove
> the ".old" suffix from /sars/apps/db/data/global/pg_control.old.
> Because "link" mode was used, the old cluster cannot be safely
> started once the new cluster has been started.
>
> Linking user relation files
> /sars/apps/db/data/sar_data/PG_9.1_201105231/29304/34537
> error while creating link for relation "public.sars_mod_cluster" ("/sars/apps/
> db/data/sar_data/PG_9.1_201105231/29304/34537" to "/sars/apps/db/data/sar_data/
> PG_9.3_201306121/16427/34537"): No such file or directory
> Failure, exiting

Wow, that is in odd error. Can you see if "public.sars_mod_cluster" is
accessible from the 9.1 cluster? My guess is you are going to get a
similar error, and the only solution is to find the missing file or
delete the table or index. Not sure how the file could have gotten
lost, but it might be file system corruption.

If my guess is wrong, please let us know.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message craig.miles0712 2013-12-03 09:20:19 BUG #8654: pg_dumpall doesnt reliably replicate source database
Previous Message Tom Lane 2013-12-03 01:31:09 Re: BUG #8648: Segmentation fault on EXISTS with no *columns*