Rich Shepard wrote:
> I think that I'm missing something very basic here, for I still cannot
> create a db. As a user (with priviledges to create and destroy db's), I cd
> to PGDATA2 (in my case ~/accounting/paisley) and issue the command:
>
> createdb -D PGDATA2 test
> or
> createdb -D /home/rshepard/accounting/paisley test
Who owns '/home/rshepard/accounting/paisley', rshepard or postgres? The
postgres user needs to own both PGDATA and PGDATA2. Also, to call up
the envvar in the shell like this, you need to call it as $PGDATA or
${PGDATA}.
See, createdb doesn't itself create the database -- it simply issues a
CREATE SQL statement to the backend to create the database. The backend
(running as user postgres) has to have permissions to the PGDATA2
structure, rshepard doesn't.
> Hmmm-m. I don't recall reading about PGPORT. Following your suggestion, I
> moved the other environment variables to /etc/profile.
PGPORT defines which port postmaster is listening on. 5432 is the
default.
> > Oh, BTW, I think the regression results you mailed me are due to locale
> > settings, as they seem to all be collation-order-dependent.
>
> That's interesting. I specified no locales, just installed the rpms.
That IS interesting. I have forwarded the results to our regression
test guru, Thomas Lockhart, to see if he can make sense of it, as a
locale issue is the only thing I can think of off the top of my head, as
I've run regression on RedHat 5.x and 6.x and never have had those two
select tests fail. To see if it is indeed a locale issue, you can get
my new non-locale RPMS from http://www.ramifordistat.net/postgres (give
me about ten minutes to get them all uploaded....) If the same failure
happens with no locale support, then something else is up.
> > The RPM environment is substantially different in scope and attitude
> > than the typical PostgreSQL installation, since RedHat elected, back at
> As a relatively new user of linux (almost two years), this doesn't make
> sense to me. PostgreSQL ought to go in /usr or /usr/local since it's an
> application, not a part of the kernel or OS utilities or required tools.
Ok, the long of it then... :-)
RedHat made it an integral part of their distribution. At the same
time, RedHat wanted to be FHS 2.0 compliant. From the FHS:
-----------FHS 2.0 (http://www.pathname.com/fhs/2.0/fhs-4.6.html) ---
4.6 /usr/local : Local hierarchy
The /usr/local hierarchy is for use by the system administrator when
installing software locally. It needs to be safe from being overwritten
when the system software is updated. It may be used for programs and
data that are shareable amongst a group of hosts, but not found in /usr.
[snip]
This directory should always be empty after first installing a
FHS-compliant system. No exceptions to this rule should be made other
than the listed directory stubs.
--------------
If you perform an 'rpm -ql' on each of the PostgreSQL RPM's, you can see
where every file goes -- most go in /usr/bin, /usr/lib,
/usr/lib/pgsql/*, or /usr/doc/postgresql-6.5.3.
So, RedHat cannot install a piece of software in /usr/local and still
claim FHS compliance. PostgreSQL is shipped as an integral part of
RedHat's distribution -- as integral as gcc, or gnuchess, or KDE. Of
course, you are not forced to install it if you don't want to; but you
do have to install in the locations that the packager built the package
for.
There are such things as relocatable packages, that allow the user a
great deal of flexibility in installation -- however, they can be
difficult to build right and can be very buggy in practice. Not to
mention difficult to help troubleshoot if the user has installed in a
'non-standard' place.
So, RedHat (in particular, Elliot Lee) made the RPM version of
PostgreSQL conform to the FHS. This entailed quite a bit of work.
I'm not saying that I agree with all the decisions made, or the current
locations used -- but, these RPMs are being shipped with current and
hopefully future versions of RedHat Linux -- the goal being a single
'standard' RPM distribution to ease the PostgreSQL developers' load in
supporting RPM users. I'd much rather compromise a little on location
purity and have a single RPM set than to be a purist and have a dozen
different 'pure' RPMs.
If it were reasonably feasible to do so, I'd make the RPM install much
more flexibly.
Hope that helps a little.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
************
