Upgrading on RH72

Patrick Nelson dijo:

Finally realized that the problems that I'm having are because my server is
RH72 running server 7.1.3-2 and my clients are RH73 running 7.2.1-5 and the
clients don't seem backward compatible. So I thought I would upgrade the
server to RH73... OK that's not going to work. So I grabbed the latest 72
rpms from a PostgreSQL mirror which have the version that looks like
7.2.1-2, so this should work. Anyone have success with this? I think it
said something about having to initdb... what does this mean?

It means you'll have to dump your database using pg_dump (of the 7.1.3
version currently installed), then upgrade (rpm -U postgresql-7.2.1),
then restore the dump (by means of psql < dump, or using pg_restore).
Be sure to read the manpages for pg_dump and pg_restore if you haven't
done so.

BTW, the PGDG RPMs should take care of the upgrading process
automatically, but there are always pitfalls so you may as well be
careful.

What does the PGDG stand for in the filename (i.e.
postgresql-7.2.1-2PGDG.i386.rpm)?

"PostegreSQL Global Development Group", as opposed to the RPMs built by
RedHat, Mandrake, etc.

--
Alvaro Herrera (<alvherre[a]atentus.com>)
"La tristeza es un muro entre dos jardines" (Khalil Gibran)

Alvaro Herrera wrote:
----------------->>>>
It means you'll have to dump your database using pg_dump (of the 7.1.3
version currently installed), then upgrade (rpm -U postgresql-7.2.1),
then restore the dump (by means of psql < dump, or using pg_restore).
Be sure to read the manpages for pg_dump and pg_restore if you haven't
done so.

BTW, the PGDG RPMs should take care of the upgrading process
automatically, but there are always pitfalls so you may as well be
careful.
----------------->>>>
Sounds good.

1. I did a pg_dumpall just in case.

2. Then I got my list of rpms which consist of:
postgresql-7.2.1-2PGDG.i386.rpm
postgresql-contrib-7.2.1-2PGDG.i386.rpm
postgresql-devel-7.2.1-2PGDG.i386.rpm
postgresql-libs-7.2.1-2PGDG.i386.rpm
postgresql-perl-7.2.1-2PGDG.i386.rpm
postgresql-python-7.2.1-2PGDG.i386.rpm
postgresql-server-7.2.1-2PGDG.i386.rpm
postgresql-tcl-7.2.1-2PGDG.i386.rpm
postgresql-tk-7.2.1-2PGDG.i386.rpm

3. Tried rpm -U postgresql-7.2.1-2PGDG.i386.rpm but it fails with:
error: failed dependencies:
postgresql = 7.1.3 is needed by postgresql-server-7.1.3-2
Am I not doing this correctly?

On Saturday 10 August 2002 01:22 pm, Patrick Nelson wrote:

Alvaro Herrera wrote:
----------------->>>>
BTW, the PGDG RPMs should take care of the upgrading process
automatically, but there are always pitfalls so you may as well be
careful.

Correction here. The PGDG RPMs _Try_ to help you, but it is far from
automatic. It is better to dump first and restore, if you can.

----------------->>>>
Sounds good.

3. Tried rpm -U postgresql-7.2.1-2PGDG.i386.rpm but it fails with:
error: failed dependencies:
postgresql = 7.1.3 is needed by postgresql-server-7.1.3-2
Am I not doing this correctly?

The PostgreSQL RPM's have a number of interdependencies. You need to rpm -U
all of the ones you want on a single line.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Patrick Nelson dijo:

3. Tried rpm -U postgresql-7.2.1-2PGDG.i386.rpm but it fails with:
error: failed dependencies:
postgresql = 7.1.3 is needed by postgresql-server-7.1.3-2
Am I not doing this correctly?

Uh, sorry. You should upgrade all RPMs at once. If the packages are
split the same way (meaning, all packages have the same name) the
simplest way should be to do

rpm -F postgresql*
(this will update the currently installed packages).

If not, the easiest is to uninstall
rpm -e postgresql postgresql-server

and then install the new version
rpm -i postgresql-7.2.1-2PGDG.i386.rpm postgresql-server-7.2.1-blah

There are other games you can play with RPM dependencies, but I will
leave that for you to investigate.

--
Alvaro Herrera (<alvherre[a]atentus.com>)
"Crear es tan dificil como ser libre" (Elsa Triolet)

OK got the upgrade installed using

rpm -Fh postgresql*

Everything went ok. The server didn't come up because the data was in a
previous format. Had already run pg_dumpall on the database so I went
straight to moving the old data out of the way:

1. in /var/lib/pgsql/data/ moved the base dir out of the way
2. did a service postgresql start and it said the initialization was OK but
server failed to start
3. in /var/lib/pgsql/ moved the data dir out of the way
4. tried step 2 again and it worked, server started
5. did psql -e template1 < pg-upg-dump.sql which errored saying couldn't
connect to <domain name of server>
6. checked /etc/init.d/postgresql and added the -o "-i" to the startup to
get it to listen
7. tried step 5 again, but this time the error is:
psql: FATAL 1: No pg_hba.conf entry for host xxx.xxx.xxx.122, user root,
database template1
xxx.xxx.xxx.122 is the IP of the pg server that I'm working on

How do I move forward if I can not get past this to ever start restoring?

On Saturday 10 August 2002 05:46 pm, Patrick Nelson wrote:

5. did psql -e template1 < pg-upg-dump.sql which errored saying couldn't
connect to <domain name of server>

6. checked /etc/init.d/postgresql and added the -o "-i" to the startup to
get it to listen

You shouldn't do that. Edit postgresql.conf (in /var/lib/pgsql/data) to do
this -- uncomment the tcpip_socket line and set it to true. This is
documented in /usr/share/doc/postgresql-7.2.1/README.rpm-dist

7. tried step 5 again, but this time the error is:
psql: FATAL 1: No pg_hba.conf entry for host xxx.xxx.xxx.122, user
root, database template1
xxx.xxx.xxx.122 is the IP of the pg server that I'm working on

How do I move forward if I can not get past this to ever start restoring?

Did you make a copy of your previous pg_hba.conf? It gets overwritten during
initdb. You will need to edit it.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Patrick Nelson dijo:

7. tried step 5 again, but this time the error is:
psql: FATAL 1: No pg_hba.conf entry for host xxx.xxx.xxx.122, user root,
database template1
xxx.xxx.xxx.122 is the IP of the pg server that I'm working on

How do I move forward if I can not get past this to ever start restoring?

You have to modify pg_hba.conf (should be in /var/lib/pgsql/data) and
add a line for xxx.xxx.xxx.122 as the comments in the file show. Note
that is it not usually considered wise to do this kind of thing using
``root''.

Maybe you can just restore the pg_hba.conf that was in the old data
directory (you probably will need to anyway).

--
Alvaro Herrera (<alvherre[a]atentus.com>)
"El dia que dejes de cambiar dejaras de vivir"

Lamar Owen wrote:
----------------->>>>
You shouldn't do that. Edit postgresql.conf (in /var/lib/pgsql/data) to do
this -- uncomment the tcpip_socket line and set it to true. This is
documented in /usr/share/doc/postgresql-7.2.1/README.rpm-dist

Did you make a copy of your previous pg_hba.conf? It gets overwritten
during
initdb. You will need to edit it.
----------------->>>>

Thanks Alvaro and Lamar!

Cool changed that startup thing as suggested.

Yes have a copy of pg_hba.conf, format doesn't seem to have changed...

I have simply host based access like:

local all trust
host all 127.0.0.1 255.255.255.255 trust
host all xxx.xxx.xxx.0 255.255.0.0 trust

A "service postgresql restart" and "psql -e template1 < pg-upg-dump.sql"
errors a bit differently:

psql: FATAL 1: user "root" does not exist

Any ideas on this one?

On Saturday 10 August 2002 06:33 pm, Patrick Nelson wrote:

A "service postgresql restart" and "psql -e template1 < pg-upg-dump.sql"
errors a bit differently:

psql: FATAL 1: user "root" does not exist

Do the psql -e as user 'postgres', not as root.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Patrick Nelson dijo:

I have simply host based access like:

local all trust
host all 127.0.0.1 255.255.255.255 trust
host all xxx.xxx.xxx.0 255.255.0.0 trust

A "service postgresql restart" and "psql -e template1 < pg-upg-dump.sql"
errors a bit differently:

psql: FATAL 1: user "root" does not exist

I guess you should start reading the manuals for things. Try to connect
using the username that your application uses.

But you'll have to createuser that user first, probably.

If then it complains that it cannot connect to the database
such-and-such, create it using createdb.

--
Alvaro Herrera (<alvherre[a]atentus.com>)
"Entristecido, Wutra
echa a Freyr a rodar
y a nosotros al mar" (cancion de Las Barreras)

Alvaro Herrera wrote:
----------------->>>>
I guess you should start reading the manuals for things. Try to connect
using the username that your application uses.

But you'll have to createuser that user first, probably.

If then it complains that it cannot connect to the database
such-and-such, create it using createdb.
----------------->>>>

I have read through most of the manual, but I don't find anything that
doesn't deal with using psql. No mater what I try to do with psql I get the
error:

psql: FATAL 1: user "root" does not exist

If I try a different user I get that user name replacing "root" above. What
is up here? This is turning into the upgrade from hell! Sorry starting to
get frustrated.