Thread: Postgres 7.0.2-2 on Red Hat 7.0?

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

Try doing CC=kgcc make

-alex

On Tue, 24 Oct 2000, Darrin Ladd wrote:

> Howdy!
>
> 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
AMDprocessor (K62). I used to have 6.5.3 installed on the same box, but running Red Hat 6.2 and it worked great!  But
now,I am having serious difficulties with the installation of 7.0.2-2.  I tried installing the binary rpm's (i386) and
Igot this error: 
>     Error: Failed dependencies:
>         libncurses.so.4 is needed by postgresql-7.0.2-2
>         libreadline.so.3 is needed by postgresql-7.0.2-2
>
> I successfully uninstalled 6.5.3, so I am pretty sure that it isn't picking up old versions.  So then I tried
compilingthe source for 7.0.2 and got this error: 
>     gcc -I../../include -I../../backend   -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I..   -c -o
>     comment.o comment.c
>     gcc -I../../include -I../../backend   -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I..   -c -o copy.o
>     copy.c
>     copy.c: In function `CopyFrom':
>     copy.c:1019: Insn does not satisfy its constraints:
>
>     (insn 89 2735 92 (set (mem:HI (plus:SI (reg:SI 6 ebp)
>                 (const_int -52 [0xffffffcc])) 0)
>         (mem/s:HI (mem:SI (plus:SI (reg:SI 6 ebp)
>                     (const_int -144 [0xffffff70])) 0) 8)) 36 {*movhi_1} (nil) (nil))
>     copy.c:1019: Internal compiler error in reload_cse_simplify_operands, at reload1.c:8110
>     Please submit a full bug report.
>     See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
>     make[2]: *** [copy.o] Error 1
>     make[2]: Leaving directory `/usr/src/redhat/SOURCES/postgresql-7.0.2/src/backend/commands'
>     make[1]: *** [commands.dir] Error 2
>     make[1]: Leaving directory `/usr/src/redhat/SOURCES/postgresql-7.0.2/src/backend
>     '
>     make: *** [all] Error 2
>
> Now, I am pretty sure that this isn't good.  So, I was wondering if this was a problem with Red Hat 7.0 or with the
wayI have setup my system. 
>
> If you have any suggestions, I would be greatly appreciative.
>
> Thanks!
> Darrin
>

"Darrin Ladd" <dladd@newfoundcomm.net> writes:

> I was wondering if anyone has installed the postgres 7.0.2-2 on Red
> Hat 7.0?

Why would you do that? We include postgresql-7.0.2-17, which basically
is the same thing and lots of minor fixes (Lamar and I cooperate on
these...)

>     Error: Failed dependencies:
>         libncurses.so.4 is needed by postgresql-7.0.2-2

ncurses4-5.0-2.i386.rpm

>         libreadline.so.3 is needed by postgresql-7.0.2-2

readline2.2.1-2.2.1-2.i386.rpm

(for anyone interested, the reason for having the version as part of
the time is that they are not the primary versions: They're old
versions included for binary compatibility)

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

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

Did you have those two dependency packages installed? I know, silly
question, but...

Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Darrin Ladd" <dladd@newfoundcomm.net>
To: <pgsql-general@postgresql.org>
Sent: Tuesday, October 24, 2000 1:14 AM
Subject: [GENERAL] Postgres 7.0.2-2 on Red Hat 7.0?


Howdy!

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). I used to have
6.5.3 installed on the same box, but running Red Hat 6.2 and it worked
great!  But now, I am having serious difficulties with the installation of
7.0.2-2.  I tried installing the binary rpm's (i386) and I got this error:
    Error: Failed dependencies:
        libncurses.so.4 is needed by postgresql-7.0.2-2
        libreadline.so.3 is needed by postgresql-7.0.2-2

I successfully uninstalled 6.5.3, so I am pretty sure that it isn't picking
up old versions.  So then I tried compiling the source for 7.0.2 and got
this error:




gcc -I../../include -I../../backend   -O2 -Wall -Wmissing-prototypes -Wmissi
ng-declarations -I..   -c -o
    comment.o comment.c




gcc -I../../include -I../../backend   -O2 -Wall -Wmissing-prototypes -Wmissi
ng-declarations -I..   -c -o copy.o
    copy.c
    copy.c: In function `CopyFrom':
    copy.c:1019: Insn does not satisfy its constraints:

    (insn 89 2735 92 (set (mem:HI (plus:SI (reg:SI 6 ebp)
                (const_int -52 [0xffffffcc])) 0)
        (mem/s:HI (mem:SI (plus:SI (reg:SI 6 ebp)
                    (const_int -144 [0xffffff70])) 0) 8)) 36 {*movhi_1}
(nil) (nil))
    copy.c:1019: Internal compiler error in reload_cse_simplify_operands, at
reload1.c:8110
    Please submit a full bug report.
    See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
    make[2]: *** [copy.o] Error 1
    make[2]: Leaving directory
`/usr/src/redhat/SOURCES/postgresql-7.0.2/src/backend/commands'
    make[1]: *** [commands.dir] Error 2
    make[1]: Leaving directory
`/usr/src/redhat/SOURCES/postgresql-7.0.2/src/backend
    '
    make: *** [all] Error 2

Now, I am pretty sure that this isn't good.  So, I was wondering if this was
a problem with Red Hat 7.0 or with the way I have setup my system.

If you have any suggestions, I would be greatly appreciative.

Thanks!
Darrin

> 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.

> 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

> > 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

"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.

"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

>  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

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

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
> 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

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