Re: Postgres 7.0.2-2 on Red Hat 7.0?

Alex Pilosov wrote:

On Tue, 24 Oct 2000, Darrin Ladd wrote:

I was wondering if anyone has installed the postgres 7.0.2-2 on Red Hat
7.0? I have Red Hat running on a box with an AMD processor (K62).

Try installing ncurses (rpmfind ncurses) and readline (rpmfind readline).

Better yet, install the PostgreSQL 7.0.2 packages that come with RedHat
7. They are derived from the 7.0.2-2 packages on the postgresql ftp
site.

On another note, look for good things in the near future on the RPM
front.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Better yet, install the PostgreSQL 7.0.2 packages that come with RedHat
7. They are derived from the 7.0.2-2 packages on the postgresql ftp
site.

RedHat's installation of PostgreSQL is abominable. It does not put it in
the default location, and it puts the binaries (psql, pg_dump, etc.) in
/bin, and the shared libraries in /lib or /usr/lib.

So, if you ever decide to upgrade, you have to go hunting in /bin and /lib
(or is it /usr/lib?) and delete all of the old files before the new
installation will work correctly. If they had just installed it in the
default directory, and put /usr/local/pgsql/bin in the path and
/usr/local/pgsql/lib in ld.so.conf, it would be good. They could even put
the base directory in /var to keep themselves happy. But the way they did
it makes upgrades very difficult.

steve

"Steve Wolfe" <steve@iboats.com> writes:

Better yet, install the PostgreSQL 7.0.2 packages that come with RedHat
7. They are derived from the 7.0.2-2 packages on the postgresql ftp
site.

RedHat's installation of PostgreSQL is abominable.

It's the same one as Lamar's, and I think it's a good one - and
complies with FHS.

It does not put it in the default location

Yes - programs, libraries in /usr, databases etc. in
/var/lib/pgsql. Nice and FHS-compliant.

and it puts the binaries (psql, pg_dump, etc.) in /bin

/usr/bin, of course, where they belong

and the shared libraries in /lib or /usr/lib.

/usr/lib - see above.

Using /usr is what distributions are supposed to do. /usr/local is for
local use, and in Red Hat typically means "not managed by
rpm". Lamar's RPMs also go in /usr - since this is the correct
location.

So, if you ever decide to upgrade, you have to go hunting in /bin and /lib
(or is it /usr/lib?) and delete all of the old files before the new
installation will work correctly.

rpm -e postgresql postgresql-devel [...other postgres packages...]

or just

rpm -e `rpm -qa|grep postgresql`

Or use gnorpm, kpackage or whatever GUI tool you prefer.

If they had just installed it in the default directory, and put
/usr/local/pgsql/bin in the path and /usr/local/pgsql/lib in
ld.so.conf, it would be good. They could even put
the base directory in /var to keep themselves happy.

We put it in the right place to keep our users happy and conform to
FHS. Distributions should never touch /usr/local.

But the way they did it makes upgrades very difficult.

Just install it in /usr (use "--prefix"), or better: Use supplied RPMs
or make your own.

--
Trond Eivind Glomsr�d
Red Hat, Inc.

It does not put it in the default location

Yes - programs, libraries in /usr, databases etc. in
/var/lib/pgsql. Nice and FHS-compliant.

By "default", I don't mean FHS-compliant. I mean the defaults that you
get if you run "./configure" in the src directory.

The last thing that a system admin needs when upgrading PostgreSQL is "Oh,
crap, I forgot to uninstall the RPM of the old one first."

steve

Distributions should never touch /usr/local.

They also shouldn't do things like install root passwords without md5
cryptography (or a hundred other things), but that doesn't seem to bother
RedHat.

steve

Steve Wolfe wrote:

RedHat's installation of PostgreSQL is abominable. It does not put it in
the default location, and it puts the binaries (psql, pg_dump, etc.) in
/bin, and the shared libraries in /lib or /usr/lib.

It is explained in numerous places (in particular, the README.rpm file
that is distributed with the RPM's) why those locations have to be the
way they are. But it boils down to PostgreSQL wanting to be installed
in a non-standard place -- standard meaning Linux Standard Base, or
Filesystem Hierarchy Standard (which is inluded in the LSB). The RedHat
RPM installation is FHS-compliant -- which RedHat desires greatly.

/usr/local/pgsql/lib in ld.so.conf, it would be good. They could even put
the base directory in /var to keep themselves happy. But the way they did
it makes upgrades very difficult.

Not if you just do 'rpm -U' -- the RPM just simply handles it. It knows
where every file is -- you need not concern yourself with those details.

Just make sure to do a pg_dumpall before upgrading.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

"Steve Wolfe" wrote:

Better yet, install the PostgreSQL 7.0.2 packages that come with RedHat
7. They are derived from the 7.0.2-2 packages on the postgresql ftp
site.

RedHat's installation of PostgreSQL is abominable. It does not put it in
the default location, and it puts the binaries (psql, pg_dump, etc.) in
/bin, and the shared libraries in /lib or /usr/lib.

So, if you ever decide to upgrade, you have to go hunting in /bin and /lib
(or is it /usr/lib?) and delete all of the old files before the new
installation will work correctly. If they had just installed it in the
default directory, and put /usr/local/pgsql/bin in the path and
/usr/local/pgsql/lib in ld.so.conf, it would be good. They could even put
the base directory in /var to keep themselves happy. But the way they did
it makes upgrades very difficult.

Red Hat is a distribution. It should not put anything in /usr/local,
which should be reserved for the _local_ adminstrator's use. If you
install a Red Hat rpm, you are installing a part of a distribution which
has to follow the distribution's rules. (The same applies to Debian,
whose PostgreSQL packages I produce.) If you use Red Hat tools to
uninstall the package, you should not need to hunt around for any files,
(provided that RH's uninstall works properly, which I assume it does.)

If you want to compile your own PostgreSQL from source, you probably
do not want to have the standard rpm installed at all.

--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"Only take heed to thyself, and keep thy soul
diligently, lest thou forget the things which thine
eyes have seen, and lest they depart from thy heart
all the days of thy life; but teach them to thy sons,
and to thy sons' sons..." Deuteronomy 4:9

"Steve Wolfe" <steve@iboats.com> writes:

Distributions should never touch /usr/local.

They also shouldn't do things like install root passwords without md5
cryptography (or a hundred other things), but that doesn't seem to bother
RedHat.

FWIW, when installing Red Hat Linux you get to choose what you want
with MD5 being the default.

Anyway, since there doesn't seem to be any substance in your mails
but your wish for Red Hat-bashing, I'll end my participation here
unless something interesting comes up.

--
Trond Eivind Glomsr�d
Red Hat, Inc.

The last thing that a system admin needs when upgrading PostgreSQL is "Oh,
crap, I forgot to uninstall the RPM of the old one first."

If you're switching from RPM to compiling source, that's your own damn
fault. If you're upgrading (rpm -U) then that isn't a concern, as it does it
for you.

Rob Nelson
rdnelson@co.centre.pa.us

Red Hat is a distribution. It should not put anything in /usr/local,
which should be reserved for the _local_ adminstrator's use.

Hmm.... so, if the local administrator wants to compile the source, it
should go in /usr/local. If he wants to use a package manager, it should go
somewhere else? Seems either pedantic or silly to me.

steve

The last thing that a system admin needs when upgrading PostgreSQL is

"Oh,

crap, I forgot to uninstall the RPM of the old one first."

Then upgrade the RPM's. It isn't hard.

OK, here's a situation. One of the programmers at your company runs the
disk out of space. You're going to go bonk him on the head, but first,
there are more pressing matters. PostgreSQL 6.5 has horked up the tables,
and needs to be fixed. 7.0 is released, which has a fix for the problem.

Are you going to sit around waiting for RPM's, while your tables are all
horked up, and the programming department is breathing down your neck
because they can't get work done?

If you're going to install from source on a RedHat machine, it is simply
prudent practice, regardless of the package, to make sure the RPM
version is not already installed.

I agree.

And, the fact of the matter is that there are likely far more PostgreSQL
installations from RPM than from source.

I fail to see the relevance of that argument. Popularity does not make
correctness. If I'm just being extremely dense about that sentence, feel
free to let me know.

steve

Hmm.... so, if the local administrator wants to compile the source, it
should go in /usr/local. If he wants to use a package manager, it should go
somewhere else? Seems either pedantic or silly to me.

Perhaps, but such is how the FHS came out. FWIW, SCO (what I work on daily)
seems to respect this designation as well.

Rob Nelson
rdnelson@co.centre.pa.us

From root Thu Oct 26 14:44:32 2000
Received: from storage.network.com (storage.network.com [129.191.1.4])
by anubis.network.com (8.9.3/8.9.3) with ESMTP id OAA05733
for <oberpwd@anubis.network.com>; Thu, 26 Oct 2000 14:44:29 -0500 (CDT)
Received: from bush.rutgersinsurance.com (rutgersinsurance.com
[38.138.71.194])
by storage.network.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21676
for <oberpwd@anubis.network.com>; Thu, 26 Oct 2000 14:44:21 -0500 (CDT)
Received: from 6014cwpza006 ([10.10.10.51])
by bush.rutgersinsurance.com (8.9.3/8.9.3) with SMTP id PAA25623
for <oberpwd@anubis.network.com>; Thu, 26 Oct 2000 15:49:38 -0400
Message-ID: <001901c03f85$79a17ac0$330a0a0a@6014cwpza006>
From: "Adam Lang" <aalang@rutgersinsurance.com>
To: "Wade D. Oberpriller" <oberpwd@anubis.network.com>
References: <200010261941.OAA12497@truck.network.com>
Subject: Re: [GENERAL] Alternate locations of DB's
Date: Thu, 26 Oct 2000 15:46:45 -0400
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

You can do that with createdb? If so, I guess that is the answer he would
be looking for. Make sure to post it to the list.

Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Wade D. Oberpriller" <oberpwd@anubis.network.com>
To: "Adam Lang" <aalang@rutgersinsurance.com>
Sent: Thursday, October 26, 2000 3:41 PM
Subject: Re: [GENERAL] Alternate locations of DB's

I don't know why you couldn't:

setenv PGDATA1 /home/user1/data
setenv PGDATA2 /home/user2/data
setenv PGDATA3 /home/user3/data
initlocation 'PGDATA1'
initlocation 'PGDATA2'
initlocation 'PGDATA3'
pg_ctl -D /home/pgsql/data start
createdb db1 -D 'PGDATA1'
createdb db2 -D 'PGDATA2'
createdb db3 -D 'PGDATA3'

You can have as many as you like, I believe.

Wade Oberpriller
StorageTek
oberpwd@network.com

But I think he wants to know how to have 3 different databases in three
different locations.

Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Wade D. Oberpriller" <oberpwd@anubis.network.com>
To: "Brian C. Doyle" <brian@jbbent.com>
Cc: "general-help postgresql" <pgsql-general@postgresql.org>
Sent: Thursday, October 26, 2000 10:16 AM
Subject: Re: [GENERAL] Alternate locations of DB's

You must use initlocation to initialize the location and have the path

to

the

location in an environment variable before postmaster is started.

For example:

setenv PGDATA2 /home/someuser/data
initlocation 'PGDATA2'
pg_ctl -D /home/pgsql/data start
createdb mydb -D 'PGDATA2'

This will start postmaster with the knowlegde of the PGDATA2

environment

variable. Then you can create databases in this alternate location.
PostgreSQL can also be compiled with an option to allow absolute

paths, so

createdb cdt -D /home/someuser/data

can be done, but I forget the option. The user's manual describes all

of

this

under CREATEDB.

Wade Oberpriller
StorageTek
oberpwd@network.com

Hello all,

How do I get Postgresql to use independantly seperate db
locations. Currently I have them under /home/user/database and as

long

as

i get postmaster to run with that same location I am fine but I want

to

have

/home/user/database
/home/user1/database
/home/userr2/database
ect...

But I can only get one instance of the postmaster running at a time

.

Steve Wolfe wrote:

Then upgrade the RPM's. It isn't hard.

OK, here's a situation. One of the programmers at your company runs the
disk out of space. You're going to go bonk him on the head, but first,
there are more pressing matters. PostgreSQL 6.5 has horked up the tables,
and needs to be fixed. 7.0 is released, which has a fix for the problem.

Not a good example, but I understand your comparison.

Are you going to sit around waiting for RPM's, while your tables are all
horked up, and the programming department is breathing down your neck
because they can't get work done?

Actually, since I'm the RPM maintainer, I'll build a set for the new
version (which I would have been tracking since the first beta) the hour
it is released. That is if I'm online when the release occurs. But,
then again, I'll have already built RPM's for the beta releases.

It's this very problem that got me in this business of maintaining the
RPM's in the first place over a year ago. Scratch that itch.....

If you're going to install from source on a RedHat machine, it is simply
prudent practice, regardless of the package, to make sure the RPM
version is not already installed.

I agree.

And, the fact of the matter is that there are likely far more PostgreSQL
installations from RPM than from source.

I fail to see the relevance of that argument. Popularity does not make
correctness. If I'm just being extremely dense about that sentence, feel
free to let me know.

The relevance is that most who use it don't really care where the stuff
is. They just want to upgrade.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

OK, here's a situation. One of the programmers at your company runs

the

disk out of space. You're going to go bonk him on the head, but first,
there are more pressing matters. PostgreSQL 6.5 has horked up the

tables,

and needs to be fixed. 7.0 is released, which has a fix for the

problem.

Not a good example, but I understand your comparison.

Why not? It's a situation that came up a couple of times on this list
right around the 7.0 release...

The relevance is that most who use it don't really care where the stuff
is. They just want to upgrade.

Well, without meaning to be rude, that seems to be an attitude that would
come from Redmond. : )

steve

OK, here's a situation. One of the programmers at your company runs the
disk out of space. You're going to go bonk him on the head, but first,
there are more pressing matters. PostgreSQL 6.5 has horked up the tables,
and needs to be fixed. 7.0 is released, which has a fix for the problem.

Let's be real here. If your system is out of disk space, you can't do a dump
to put it into 7.0. You're definitely gonna need 6.5 to work at this
point...

Are you going to sit around waiting for RPM's, while your tables are all
horked up, and the programming department is breathing down your neck
because they can't get work done?

If 7.0 is that important, and there's no RPM's yet (which is a case I
haven't seen happen yet) then you should compile from source, but make the
RPM as you compile. It'll add about 5 minutes to your task, and save you a
world of pain if you have more than one machine to fix.

Your problems aren't with RPM's, your problems the FHS. Distrib packages
(RPM *or* DEB) will put stuff in FHS compliant locations, packages by anyone
else will put files where they want. If you feel that's incorrect,
Irespectfully suggest you hit up the LSB/FHS people if you want that to
change, NOT Red Hat, PostGreSQL, or anyone else.

Rob Nelson
rdnelson@co.centre.pa.us

I think the point is, is that it is the attitude that come from a lot of end
users, not developers.

Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Steve Wolfe" <steve@iboats.com>
To: <pgsql-general@postgresql.org>
Sent: Thursday, October 26, 2000 8:06 PM
Subject: Re: [GENERAL] Postgres 7.0.2-2 on Red Hat 7.0?

<snip>

The relevance is that most who use it don't really care where the stuff
is. They just want to upgrade.

Well, without meaning to be rude, that seems to be an attitude that

would

hello,

I have a problem with a rule "on insert"

I have a table "my_table" with a field named "index"
that has a default value of "nextval('seq')"

and the folowing rule
------------------------------------------------------
CREATE RULE log_ins AS ON INSERT TO my_table
DO INSERT INTO log(tbl,idrow,query,time)
VALUES('my_table',NEW.index,'INSERT','now'::text) ;
-----------------------------------------------------

my problem is:

in "log" table I have for "NEW.index" a value of 13
amd in "my_table" I have for "NEW.index" a value of 14
always (+1) which is the increment of sequence "seq"

can someone help me ?

P.S. what is the suntax for multiple actions in a rule ?

-razvan-

OK, here's a situation. One of the programmers at your company runs

the

disk out of space. You're going to go bonk him on the head, but first,
there are more pressing matters. PostgreSQL 6.5 has horked up the

tables,

and needs to be fixed. 7.0 is released, which has a fix for the problem.

Let's be real here. If your system is out of disk space, you can't do a

dump

to put it into 7.0. You're definitely gonna need 6.5 to work at this
point...

I know. And I was being real. That is the situation that happend at my
company, and it also came up from at least one other person on the list.
Yes, I needed 6.5 to get the data out. However, you *couldn't* dump the
data, PSQL had horked the tables up too badly. I ended up writing a Perl
script to get things from the tables, and put them into a flat file of SQL
statements. It was ugly, but the clock was ticking. ; )

(nothing like a junior programmer doing a recursive grep of a large file
system, and redirecting the results to a file *in* the filesystem he's
grepping)

Your problems aren't with RPM's, your problems the FHS. Distrib packages
(RPM *or* DEB) will put stuff in FHS compliant locations, packages by

anyone

else will put files where they want. If you feel that's incorrect,
Irespectfully suggest you hit up the LSB/FHS people if you want that to
change, NOT Red Hat, PostGreSQL, or anyone else.

I think you're missing the subtlety of my point, but that's fine.
You're correct that this isn't the list, I'm going to drop the topic.

steve