Re: Conservation of OIDs - Mailing list pgsql-general

From
Subject Re: Conservation of OIDs
Date
Msg-id 64635.216.238.112.88.1069077765.squirrel@$HOSTNAME
Whole thread Raw
In response to Re: Conservation of OIDs  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
List pgsql-general
>
> On Sun, 16 Nov 2003, Alvaro Herrera wrote:
>
>> On Sun, Nov 16, 2003 at 10:47:22AM -0800, Joshua D. Drake wrote:
>> >
>> > >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...
>>
>> What's the point?  You can keep them separate through pg_hba.conf if
>> it's really needed.  I don't see how having several clusters, one
>> database each, buys you any security.

Using a separate cluster for each, or at least one cluster for PROD and
one for both QAT and DEV does address the original question posed about
burning through OIDS during the refresh->modify->test->fix iteration.

>
> I don't think security isn't the issue but instead it's reliability. If
> you have a bug in your dev system that say causes backends to die and
> forcing full postmaster restarts, do you really want to be mucking up
> your production system as well? This isn't hard to imagine ...
>

I can see the reliability thing being a big plus, too. While I don't care
if developers accidentally drop an important table in DEV, if they hang
the production postmaster or otherwise screw up the server, then that is
undesireable.

The complications (real or imagined at this point) of using different
port numbers has me kind of stuck, however.

So, help me out with some specifics of the multi-cluster route, and lets
pretend I can't afford another machine (actually the hardware acquisition
is not a problem, but I don't want to incur the additional server setup
and maintenance responsiblity). I create a new cluster with

initdb -D /path/to/my/qat/cluster
initdb -D /path/to/my/dev/cluster


right? Then that means that I need to maintain separate pg_hba.conf and
postgresql.conf files for each (in the respective cluster directories),
right?

Then I restore into the new QAT and DEV cluster my backup from PROD, but
exactly how is that done? I guess I have to employ the -p option with
psql, something like

psql -p 5433 -U postgres -f my_prod_backup.sql myqatdb
psql -p 5433 -U postgres -f my_prod_backup.sql mydevdb

(I guess I can use the same database name if I'm using separate
clusters?) assuming I've modified the QAT and DEV postgresql.conf files
to specify that port, or possilby started postmaster with

postmaster -p 5433

for qat and maybe

postmaster -p 5434

for dev.

Actually, the two postmaster commands above are probably wrong. Instead,
is what I need

postmaster -D /path/to/my/qat/cluster

and

postmaster -D /path/to/my/dev/cluster


so that the proper port is picked up from the respectively-modified
postgresql.conf files in the separate cluster directories?

And how would I automate the QAT and DEV postmaster startup with server
startup, the way the current postmaster is started with all three
databases in a single cluster, on my RH Linux host that uses the
rc.d/init.d/postgresql script? Would it be necessary to make a qat and
dev version of that stgartup script, appropriately modified to use the
different cluster directories, or what?

~Berend Tober




pgsql-general by date:

Previous
From: Paul Thomas
Date:
Subject: Re: Newbie: FAQ - change root password?
Next
From: Doug McNaught
Date:
Subject: Re: Conservation of OIDs