initdb on build machine and moving to production machine
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