Uninstall mess Postgresql 7.3.4, 8.1.4 on Redhat 9

On Tue, Sep 18, 2007 at 03:06:32PM -0700, MargaretGillon@chromalloy.com

wrote:

account and the system's knowledge of the posgresql 8.1.4 software.

The

system will no longer run 8.1.4 even when I go to the /bin/ to run the
commands. The data is still present and so is the 8.1.4 software. I

remade

What happens then? Error messages? It's hard to tell what the
problem might be.

When the system boots there is a FAILED error when the server tries to
load postgresql8.

If I manually run
/etc/rc.d/init.d/postgresql8 start
the message is
standard in must be tty
[FAILED]

the postgres account on the server and gave it permission's to 8.1.4
directories but still no dice. I have multiple backups of the database
that are okay.

How did you remake the account? Same UID?

I don't know what the UID was. I used adduser to remake the postgres
Redhat account.

Would my best bet be to download and install 8.2.5 and import the

backup?

Or do I need to get 8.1.4 running, and how do I do that?

Adding 8.2.x to your headaches won't make it better, for sure -- it's
just another layer of incompatibility.

If versions can run in parallel why would installing the new version
affect the 8.1.4 version?

Margaret Gillon

On Wed, Sep 19, 2007 at 08:52:29AM -0700, MargaretGillon@chromalloy.com wrote:

When the system boots there is a FAILED error when the server tries to
load postgresql8.

If I manually run
/etc/rc.d/init.d/postgresql8 start
the message is
standard in must be tty
[FAILED]

This suggsts your init script is broken. You ought to be able to
test whether postgres will run properly by setting PGDATA correctly,
and then running /path/to/pg8.x/bin/pg_ctl start. Whether postgres
will run is not exactly the same question as whether your init script
is correct.

How did you remake the account? Same UID?

I don't know what the UID was. I used adduser to remake the postgres
Redhat account.

But adduser likely changed the UID of the postgres account, and if
the old binaries or data directory were owned by a deleted user, then
the ownership is probably still held by that UID. (I can't be sure
how RH does this, but on every other UNIX I've ever used, useradd
foo; userdel foo; useradd foo causes the second "foo" user to have a
different UID than the first one.)

This would mean that the "new" postgres user still doesn't own the
data areas of the "old" postgres installation. You could discover
this by finding out the ownership of the data files (e.g., by using
ls -l).

Adding 8.2.x to your headaches won't make it better, for sure -- it's
just another layer of incompatibility.

If versions can run in parallel why would installing the new version
affect the 8.1.4 version?

It wouldn't, but your old data still need to be dumped and restored;
and without a running 8.1, that won't help you. Unless you mean that
you'd install 8.2.x and load from a backup. Even there, you might
have problems, because when doing an upgrade, you need to pg_dump
with the new pg_dump, not the old one.

A

--
Andrew Sullivan | ajs@crankycanuck.ca
However important originality may be in some fields, restraint and
adherence to procedure emerge as the more significant virtues in a
great many others. --Alain de Botton

This suggsts your init script is broken. You ought to be able to
test whether postgres will run properly by setting PGDATA correctly,
and then running /path/to/pg8.x/bin/pg_ctl start. Whether postgres
will run is not exactly the same question as whether your init script
is correct.

The /data directory was owned by Postgres user. I ran the command you sent
and the system didn't like it because root owned the /bin directoy. I
changed the owner to postgres and now the message that I get is
pg_ctl: no database directory specified and environmental variable PGDATA
unset

It wouldn't, but your old data still need to be dumped and restored;
and without a running 8.1, that won't help you. Unless you mean that
you'd install 8.2.x and load from a backup.

Yes, that's what I meant.

Even there, you might
have problems, because when doing an upgrade, you need to pg_dump
with the new pg_dump, not the old one.

The database is very simple, probably doesn't have any version specific
code. There are no blobs. It was backed up in plain text. This is my
backup command.

su --command="/usr/local/pgsql/bin/pg_dump -p 55432 -U postgres -C -D -f
/tmp/$(date +%F)owl.sql owl"

Margaret Gillon

Andrew Sullivan <ajs@crankycanuck.ca> wrote on 09/19/2007 10:12:26 AM:
It wouldn't, but your old data still need to be dumped and restored;
and without a running 8.1, that won't help you. Unless you mean that
you'd install 8.2.x and load from a backup.

Thank you for your help. I wasn't able to repair the 8.1.4 install but I
moved it out of the way before installing 8.2.5 so it is still intact. I
was able to push my database into the newer version from the sql backup
file. I am hoping to fix the 8.1.4 version next week. I now have breathing
space since the database is back on-line in the 8.2.5 version, my clients
can attach, and my backup is functional.

Margaret Gillon