On 12/26/2013 08:31 AM, Joseph Kregloh wrote:
> As suggested I did a couple more experiments. This time I installed
> Postgres 9.0 in it's defauls location. I then installed Postgres 9.3 in
> /opt. Tested that both version booted up and ran independently of each
> other.
>
> First test, Postgres 9.0 just after an initdb, so it's all clean. It
> completed successfully and created the analyze_new_cluster and
> delete_old_cluster scripts. So this was successful.
>
...
> Second test. I cleaned up the data folders for both installs and did
> initdb on both installs. This time I created one table space. It
> completed the upgrade, however it only created the analyze_new cluster
> script. No delete_old_cluster script. I created the symlink from the new
> install pointing to the old data folder, which is to be expected. But it
> left the old data there.
>
>
> Could not create a script to delete the old cluster's data
> files because user-defined tablespaces exist in the old cluster
> directory. The old cluster's contents must be deleted manually.
>
Here is the message on --hackers that explains the above:
http://www.postgresql.org/message-id/20130214052952.GA10606@momjian.us
>
> While the upgrade was successful, I find it unusable and leaving me with
> a lot of manual labor ahead of me. Because it leaves the old folders
> there, which have to be deleted manually. The same with all the other
> data files, like postgresql.conf for example. Something that
> uninstalling 9.0 doesn't remove. In other words now I am left with a
> dirty /usr/local/pgsql/data folder and having to modify the postgres
> startup script. Or manually delete all the files and folders I don't
> want and reinstall Posgres 9.3 in the default location and create new
> symlinks.
Well one of the options in the upgrade process is to move the old
installation out of the way into another directory and then install the
new version into the default location. That would eliminate the above
issues.
>
> -Joseph
--
Adrian Klaver
adrian.klaver@gmail.com