Thread: initdb on build machine and moving to production machine
initdb on build machine and moving to production machine
From
oberpwd@anubis.network.com (Wade D. Oberpriller)
Date:
Hello, I want to be able to do an initdb on a build machine and then copy this new database to a production machine and run with it. One thing I have noticed is that initdb needs an absolute path, so if I copy the database it needs to reside in an identical location as where it was initialized. The problem is my build machine and production machines don't have the same directory structures. One solution I was considering was to create an alternative path through symbolic links to my directory where I do the initdb on the build machine. This alternative path would match the path that the db will reside in on the production machines. Is there anyway to overcome this, that is can a database be initialized and copied to another locationa and still work? Wade Oberpriller StorageTek oberpwd@network.com
Wade D. Oberpriller writes: > I want to be able to do an initdb on a build machine and then copy this new > database to a production machine and run with it. One thing I have noticed is > that initdb needs an absolute path, so if I copy the database it needs to > reside in an identical location as where it was initialized. No. The path is only used within initdb to find the directory. It's not saved anywhere. > Is there anyway to overcome this, that is can a database be initialized and > copied to another locationa and still work? This should work painlessly if both machines are the same platform. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
oberpwd@anubis.network.com (Wade D. Oberpriller) writes: > I want to be able to do an initdb on a build machine and then copy this new > database to a production machine and run with it. One thing I have noticed is > that initdb needs an absolute path, so if I copy the database it needs to > reside in an identical location as where it was initialized. Have you tried it? AFAIK the -D path is not actually stored anywhere, so it seems to me this would work, assuming that (a) both machines are of identical architectures (in fact I strongly suggest you be running identical postgres executables), and (b) you shut down the postmaster on the source machine while you make a copy of the $PGDATA tree. The *whole* $PGDATA tree, mind you, don't try to be choosy. But you should be able to restore that directory tree to a different path if you want. regards, tom lane