On Mon, Dec 5, 2011 at 7:34 AM, Bruce Momjian <bruce@xxxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
