Re: Conservation of OIDs
От | Joshua D. Drake |
---|---|
Тема | Re: Conservation of OIDs |
Дата | |
Msg-id | 3FB7C63A.7080007@commandprompt.com обсуждение исходный текст |
Ответ на | Re: Conservation of OIDs ("Nigel J. Andrews" <nandrews@investsystems.co.uk>) |
Ответы |
Re: Conservation of OIDs
|
Список | pgsql-general |
>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 - jd@commandprompt.com - http://www.commandprompt.com PostgreSQL.Org - Editor-N-Chief - http://www.postgresql.org
В списке pgsql-general по дате отправления: