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  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Error on initdb with 7.4RC2
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: how to find version?