Re: Conservation of OIDs

On Fri, 14 Nov 2003 btober@seaworthysys.com wrote:

>
> > On Fri, 14 Nov 2003 10:01:51 -0500 (EST), <btober@seaworthysys.com>
> > wrote:
> >>The Production database is the "real" data, and we periodically take a
> >> back up from Prod and re-instantiate QAT and DEV by dropping them and
> >> then restoring from the Prod backup.
> >
> > OIDs are unsigned 32 bit...you still have more than 4000000000 for your
> > objects.  How many objects (tables, indices, operators, functions, ...)
>
> Only several thousand, so as a practical matter I realize in this case it
> realistically is not a problem, but for the sake of completenss in
> understanding how I *could* do this, I'd like to learn.
>
>...
>
> > ...you can initdb separate clusters for QAT
> > and DEV and run three postmasters using three different ports.
>
> This is what I was thinking but didn't really understand fully what I
> would have to do. So your suggestion involves
>
> initdb -D my_QAT_path
>
> then
>
> psql -f my_PROD_backup.sql ... [?]
>
> Can you help me out with a little more detail and tell me where does the
> "different port" assignement come into play? I know I have the default
> port 5432 in my postgresql.conf file, but how do I associate different
> ports with the different postmasters? I guess the -h option on the start
> command line, but my RH Linux machine is setup up start the postmaster
> automatically on startup, using the /etc/init.d/postgresql script file.
> How would I get the postmaster to auto start multiple instances using the
> different port configurations?

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 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