Thread: Uninstall mess Postgresql 7.3.4, 8.1.4 on Redhat 9
I had two versions of postgresql running on a Redhat 9 server. Today I shut down the 7.3.4 version and uninstalled it using the RPM's. Unfortunately, as far as I can tell, this deleted the postgres user 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 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.
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?
Please reply to me as well as the list as I am on the digest version.
TIA
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Margaret Gillon, IS Dept., Chromalloy Los Angeles, ext. 297
This e-mail message and any attachment(s) are for the sole use of the intended recipient(s) and may contain proprietary and/or confidential information which may be privileged or otherwise protected from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient(s), please contact the sender by reply email and destroy the original message and any copies of the message as well as any attachment(s) to the original message.
>>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