Whoa! You mean these aren't already separate database clusters or even separate systems? I am very shocked, you can't do a proper Dev --> QAT --> Prod environment if all three systems are run by the same postmaster, or on the same host imo. But maybe I'm just over cautious, or worked on systems where access to production systems is controlled.
I second this. Use different databases for each. You can run them on the same machine (there are some real advantages to this) but create a separate initdb for each... Then run PostgreSQL on its own port for each.
If you really want to make it structured create virtual IP addresses for each so that you never think about it...
dev.database.com qat.database.com prod.database.com
I can see the advantages in that Dev and QAT environments are automatically the same as Prod but in general Dev can be a law unto itself almost and QAT reflects the environment of Prod, e.g. Prod is Solaris 5.9 so QAT is Solaris 5.9, with the only differences being changes applied to QAT that have not yet been applied to Prod, and Dev could be Windows if that can provide everything needed to develop for the end product.
At the very least I think your three database should be run as separate clusters, indeed reading the section I edited out from your email about the usage pattern on QAT and Dev my first thought was "Well if you think oid wrap around would be a problem just throw an initdb into your rebuild cycle."
I've seen some useful replies on how to run these separately but am I the only one shocked that the whole process is happening on a production system?
-- Nigel Andrews
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
-- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC - S/JDBC Postgresql support, programming, shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL.Org - Editor-N-Chief - http://www.postgresql.org
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
