Re: pg_upgrade FAIL: can't find tablespaces

On Thu, Aug 21, 2014 at 06:54:06AM -0700, Craig James wrote:
> pg_upgrade ran with no complaints. The new directory was /data/postgres-9.3.
>
> Since I wasn't going to run 8.4 any more, I updated the symlink /postgres to
> point to /data/postgres-9.3. Unfortunately, pg_upgrade hadn't created /data/
> postgres-9.3/tablespaces, since it thought they were in /postgres/tablespaces:
>
>     /data/postgres-9.3/main/pg_tblspc/nnnnn -> /postgres/tablespaces/xxx/
>
> where "nnnnn" is the ID of the tablespace and "xxx" was the original tablespace
> name. When I tried to start 9.3, I got the errors shown in my original email.
>
> To fix it, I simply moved /data/postgres-8.4/tablespaces to /data/postgres-9.3/
> tablespaces.

Thanks for the explanation. I wanted to make sure I wasn't missing
something.

> One scary side effect: if I had run the cleanup script that pg_upgrade
> produced, it would have deleted my entire database since /data/postgres-8.4/
> tablespaces was NOT hard linked into the new /data/postgres-9.3 directory.

Yes, very scary. We have a test in the code to see if you have placed
the tablespace inside the old cluster, but it can't check symlinks. We
also mention this in the docs:

Once you are satisfied with the upgrade, you can delete the old
cluster's data directories by running the script mentioned when
<command>pg_upgrade</command> completes. (Automatic deletion is not <--
possible if you have user-defined tablespaces inside the old data <--
directory.) You can also delete the old installation directories <--
(e.g. <filename>bin</>, <filename>share</>).

Not sure what more we can do.

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

+ Everyone has their own god. +