Re: [ANNOUNCE] i386 RPMs available for v6.5.1 - Mailing list pgsql-hackers

From Rich Shepard
Subject Re: [ANNOUNCE] i386 RPMs available for v6.5.1
Date
Msg-id Pine.LNX.4.10.9907270947380.22852-100000@salmo.appl-ecosys.com
Whole thread Raw
In response to Re: [ANNOUNCE] i386 RPMs available for v6.5.1  (Thomas Lockhart <lockhart@alumni.caltech.edu>)
List pgsql-hackers
On Tue, 27 Jul 1999, Thomas Lockhart wrote:

> (back on list, since this is a topic of general RH interest imho)
 Makes sense to me.
> RPMs install files into /usr/{bin,lib} and /var/lib/pgsql because
> these same (or similar) RPMs are shipped by RedHat as part of their
> distribution.
 I have /usr/bin/postgres and /usr/local/pgsql/doc/* with user postgres
based in /home/postgres. And, of course, /etc/rc.d/init.d/posgresql. If I
understand your message, the only difference I will see by removing all this
and replacing it with the 6.5.1 rpm is that postgres' home directory and the
docs will be in /var and the binary will be in /var/lib rather than
/usr/bin. Is this correct? 
> RH feels constrained to *only* install binaries, libraries, etc, into the
> "standard places" which leaves no room for alternatives. As you may know,
> file system layout has been a hot topic for Linux standardization, and
> there isn't much point in trying to fight it, or trying to push RH away
> from their choices ;)
 I certainly did not mean to imply that I'm against the nacent standard for
linux file systems! :-) I think that's a Real Good Thing. But, I didn't use
the rpm for 6.4.2 because I couldn't get alternative directories to work ...

> I *believe* that the v6.5.x RPMs will allow you to define your data
> directories, but I agree that it isn't clear how to do this. fyi, the
> way to do this is to use initdb with PGDATA pointed at your desired
> target directory. You might try using "initlocation" to prepare that
> target directory, or you can do this manually.
... despite having done all this. I defined PGDATA2 in ~/.bash_profile as
/home/rshepard/data/accounting. I then ran (as root) initlocation. When I
tried to use pgsql to open a file there, I received error messages that the
directory (or the ../base directory) didn't exist. When I use the source
installation, it works.

> You would also modify /etc/rc.d/init.d/postgresql.init to point to the
> right place.
 I have a /etc/rc.d/init.d/posgresql script (no .init). I see references in
there to the postmaster at /usr/bin and a series of references to files in
/var/lib. So, I assume that I need only change the /usr/bin paths to
/var/lib paths to make the upgrade work. Correct?
> pretty fixed). If you (or anyone else) would like to do the RPM
> installation for v6.5.1 to upgrade your v6.4.2 system, I'd be happy to
> help walk you through it, and we can capture that info for the next
> round of docs.
 This evening, after work and after I replace the (!!&*%(*)#$%#  Seagate tape
drive which died on my after only a year.

Thanks, Thomas!

Rich

Dr. Richard B. Shepard, President
                      Applied Ecosystem Services, Inc.           2404 SW 22nd Street | Troutdale, OR 97060-1247 |
U.S.A.+1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com             Making
environmentally-responsiblemining happen.
 



pgsql-hackers by date:

Previous
From: wieck@debis.com (Jan Wieck)
Date:
Subject: Re: dynloader and PLs [was: plperl intial pass]
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] UPDATE performance degradation (6.5.1)