Обсуждение: Upgrading on RH72
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? What does the PGDG stand for in the filename (i.e. postgresql-7.2.1-2PGDG.i386.rpm)?
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?
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.
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