Tory M Blue wrote: > So we are making progress on our performance issues, we are splitting > the data, changing the index value etc. So far having some success, > but we also want to test out some of the options and changes in the 9 > branch, but trying to dump and restore 750gb of data is not all that > fun, so I'm trying to avoid that. > > So upgraded from 8.4.4 64 bit to 9.1.1 64bit. > > If we upgrade a database that just uses the public table space there > are no issues, works fine. However when we try to upgrade a db that > has tablespaces defined it errors out trying to load the data from the > then now new db. > > The tablespaces are hardcoded with a path, so that seems to cause issues. > > Steps I'm taking > > Standard location of data /data/db > Standard binary location /pgsql/bin > > I'm moving the standard location to /data1/db and moving the binaries > to /pgsql8/bin > > WHY: because my build scripts put my binaries and data in these > locations, so without recreating my build process, I have to move the > current data and binary locations before I install 9.11 > > So I move olddata to /data1/db > oldbinary to /pgsql8/bin > > new 9.1.1 db goes to /data/db > newbinary installs at /pgsql/ > > So when I run pg_upgrade (check validates the config), however trying > to the upgrade nets; > Restoring user relation files > /data/queue/16384/16406 > error while copying queue.adm_version (/data/queue/16384/16406 to > /data/queue/PG_9.1_201105231/16407/16406): No such file or directory > Failure, exiting > > As you can see, it's sticking with it's original path and not > realizing that I'm trying now to install into /data from /data1 > > What is the flaw here? Do I have to rebuild my build process to > install in a different location?, not sure what my choices are here. I > mean I'm telling the upgrade process where new and old are located, I > believe it should be overriding something and not allowing the > included error. > > Slaps and or pointers are welcome Well, I am not totally clear how you are moving things around, but I do know pg_upgrade isn't happy to have the old and new cluster be very different. What I think is happening is that you didn't properly move the tablespace in the old cluster. We don't give you a very easy way to do that. You need to not only move the directory, but you need to update the symlinks in data/pg_tblspc/, and update the pg_tablespace system table. Did you do all of that? Does the 8.4 server see the tablespace properly after the move, but before pg_upgrade? -- Bruce Momjian <bruce@xxxxxxxxxx> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
