On 12/20/06, Tom Kalafut <tommyk@xxxxxxxxxxx> wrote:
After consulting with a teammate, I've found out that they'd have no problem simply doing 2 separate makes. In fact, I'm glad. It's makes much better sense.
i really dont much understand what you have decided to do. have you considered creating two separate databases in same postgresql installation ?
Thanks, Tom Tom Kalafut Interchange/CG Crew Member Trident Systems Inc. tommyk@xxxxxxxxxxx (919)388-1264 ------------------------- The opinions expressed in this email may not necessarily reflect the opinions of Trident Systems Inc. -----Original Message----- From: Rajesh Kumar Mallah [mailto:mallah.rajesh@xxxxxxxxx] Sent: Tuesday, December 19, 2006 1:26 PM To: Tom Kalafut Cc: pgsql-admin@xxxxxxxxxxxxxx Subject: Re: [ADMIN] multiple postgres instances from RPM install On 12/19/06, Tom Kalafut <tommyk@xxxxxxxxxxx> wrote: > > > > > I am getting ready to set up 2 postgres instances, but I'm somewhat new to > postgres. I've used RPM to list out all the files that are installed, and I > think I've isolated all the executables of which I need to make separate > copies, but I was hoping for some confirmation. please read about initdb you can initdb two different empty directories as two different unix users. when you initdb a directory you will get a postgresql.conf file in it. you can change the port number in that file to run different instances separately. but do you really need two different instances that would possibly compete each other for resources? I heard the exact files > that need copying are listed in a thread somewhere in the archives, but I > can't seem to find it. Could someone please point me to it? > > > > The motivation behind this is having 2 distinct SELinux policies for 2 > separate users with their own separate databases. > > > > Thanks, > > Tom > > > > > > Tom Kalafut > Interchange/CG Crew Member > Trident Systems Inc. > tommyk@xxxxxxxxxxx > (919)388-1264 > > > > ------------------------- > > The opinions expressed in this email may not necessarily reflect the > opinions of Trident Systems Inc. > >
