Re: pg_upgrade & tablespaces

From: Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com>
To: Joseph Kregloh <jkregloh(at)sproutloud(dot)com>
Cc: John R Pierce <pierce(at)hogranch(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: pg_upgrade & tablespaces
Date: 2013-12-27 21:15:55
Message-ID: 52BDEE0B.6010809@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On 12/27/2013 01:00 PM, Joseph Kregloh wrote:
>
> Postgres is going to /usr/local/pgsql/data/drupal___dbspace/ to look
> for the 9.0 files instead of
> /usr/local/pgsql_90/data/__drupal_dbspace/ and is trying to copy
> them as 9.3 versions into the new default location which has the
> same path. Since the new
> /usr/local/pgsql/data/drupal___dbspace/PG_9.0_201008051 is empty it
> is failing.
>
>
> That is exactly what is going on. I think what I am going to end up
> doing is:

I am not sure that is going to work.

>
> - Leaving 9.0 in the default location, this way it will successfully
> complete PG upgrade.

So you will have 9.3 installed in /opt correct?

> - Uninstall 9.0
> - Manually move the user created tablespaces into the 9.3 data folder

The 9.0 tablespaces correct? Why, this after the upgrade they are no
longer of use to the 9.3 installation and cannot be used by it?

> - Reinstall 9.3 to go into the default location, right now its installed
> in /opt using the PREFIX

Now 9.3 is in /usr/local/ correct?

> - Move the 9.3 data folder into the default location.

Same problem, different direction:) The 9.3 tablespaces in pg_tablespace
will be looking back at the old /opt location which does not exist

> - Cleanup the old 9.0 folders

>
> Then in theory it should start right up.
>
> I would assume that if the user created tablespaces were created outside
> of the /data folder then this would not be an issue. But again, I am not
> the DBA, I clean up after everybody else.

Well the idea behind user created tablespaces is to spread the data load
across filesystems/disks. So, yes it is generally best practice not to
put them in the default PGDATA directory.

>
> Thanks for all your help Adrian.
>
> -Joseph

--
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Chris Curvey 2013-12-27 21:18:12 Re: ON_ERROR_EXIT and interactive mode (or, how to force interactive mode off)
Previous Message Joseph Kregloh 2013-12-27 21:00:56 Re: pg_upgrade & tablespaces

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2013-12-27 21:46:37 Re: [BUGFIX] Typos when using the memcmp() function.
Previous Message Peter Eisentraut 2013-12-27 21:05:24 Re: Question about Lockhart's book