Re: pg_upgrade

On Mon, Dec 5, 2011 at 7:34 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Nicholson, Brad (Toronto, ON, CA) wrote:
>>
>> Based on the OP this does not seem like a messed up configuration.  It
>> sounds like the OP used a fully supported core feature of Postgres
>> (tablespaces) and pg_upgrade failed as a result.  I think having our
>> upgrade utility fail under such circumstances is a bad thing.
>
> The OP has not indicated exactly what he did to move the tablespaces, so
> I have to assume he changed the SQL location but not the symbolic link
> location, or some other misconfiguration.  Can someone provide the steps
> that caused the failure?
>
> pg_upgrade works fine for tablespaces so there must be something
> different about his configuration.  Unless I hear details, I have to
> assume the tablespace move was done incorrectly.  This is the first
> tablespace failure like this I have ever gotten, and I do test
> tablespaces.  Perhaps something is wrong, but I can't guess what it is.
>

Sorry for the late response, I didn't mean to host a party and step out!

Bruce is right, I didn't move tablespaces (I didn't know to be honest
I had to, but it makes sense). I simply moved the location of the data
files, from /data to /data1. But I did "not", change any sym links or
do any other pre-steps, other than install the new binary, make sure
that there was a new and old data location as well as a new and old
binary location.

Since my build processes installs data files at /data and binary at
/pgsql/, I simply moved the old Data and binaries, before installing
my new build. So /pgsql/ became /pgsql8/ and /data/ became /data1/

I do understand what you are all saying in regards to the tablespace
links and tablespace locations.It made total sense when Bruce pointed
it out initially. However I'm not sure if I should of known that
pg_upgrade doesn't handle this, and or this would be a concern.
pg_upgrade asks for old and new locations, so one would think that
this information would be used for the upgrade process, including
potentially changing tablespace paths during the migration step
<shrug>, this is above my pay grade.

But initial response to all this, is umm we have not really made a
dump/restore unnecessary with the latest releases of Postgres than, as
I would have to think that there is a high percentage of users whom
use tablespaces.

Tory